DZone.com Feed 日本語 ノート

DZone.com Feed 日本語

DZoneは、技術とプログラミングの多くの側面に焦点を当てる包括的なオンラインプラットフォームです。このサイトは、異なるプログラミング言語、技術、フレームワーク、ツールに関する豊富な情報を提供します。サイト上で利用できる主な機能とリソースには、技術セクターの最新のトレンドと更新に関するニュースと記事、異なるプログラミングスキルを学ぶための多くのリソースとチュートリアル、ユーザーが互いに交流し、経験と知識を共有するコミュニティがあります。さらに、DZoneはテックプロフェッショナル向けの求人情報も提供し、技術とプログラミングに興味のある人々にとって有用なリソースとして機能します。

ノートのスレッド

多くの人は、ソフトウェアエンジニアリングにおけるリーダーシップは、コーディングをやめてマネージャーになってから始まるものだと考えています。私もかつてはこの考えを共有しており、テクノロジーは人間関係よりも単純だろうと思っていました。それは初期の誤解でした。コード、アーキテクチャ、データベース、その他の技術分野にキャリアを集中させることは可能ですが、あなたの影響力を形作る課題は、時間の経過とともに技術的なものから離れていきます。たとえ最高のアーキテクチャ上の決定であっても、他者がそれを信頼し、理解し、支持しなければ、ほとんど価値がありません。これは、経験豊富なすべてのソフトウェアエンジニアがマネージャーになるべきだという意味ではありません。リーダーシップは、技術的なトラックにおいても同様に重要です。スタッフエンジニア、アーキテクト、プリンシパルエンジニアなどのシニア個人貢献者は、自身のコードを超えた意思決定に影響を与えることが期待されます。Will LarsonがStaff Engineerで論じているように、シニアエンジニアリングを超えて進むことは、ピープルマネジメントよりもテクニカルリーダーシップに焦点を当てます。あなたの技術的な影響力を高めるためには、他者はあなたのアイデアに耳を傾け、あなたの判断を信頼し、重要な議論にあなたを含め、あなたの推奨事項に基づいて行動する必要があります。あなたはピープルマネジメントを選択しないかもしれませんが、リーダーシップを避けることは、最終的にソフトウェアエンジニアとしてのあなたの成長を制限するでしょう。
デモは常にうまくいく。誰かがノートブックで基盤モデルにベクトルインデックスを接続し、従業員ハンドブックについて3つの質問をすると、3つの的確な回答が得られ、部屋はうなずく。その後、「4,000人の従業員に出荷する」という要求になり、ノートブックは静かに死ぬ。エンドポイントがなく、認証がなく、バージョン履歴がなく、特定の回答がなぜ間違っていたのかを確認する方法がなく、法務部から「2019年のPTOポリシーを引用し始めたプロンプトをどのようにロールバックするのか」と尋ねられたときのストーリーがない。私はいくつかのチームがこの壁にぶつかるのを見てきた。RAGの部分 — チャンク化、埋め込み、取得、コンテキストの詰め込み、生成 — は彼らは熟知している。彼らが欠いているのは、退屈な半分だ。ノートブックのセルで実行されるチェーンを、チャットUIが呼び出すことができる、午前3時のアラートにも耐えられる、来月宇宙全体を再デプロイすることなくA/Bテストできる、管理され、バージョン管理され、監視されたRESTエンドポイントにどうやって変換するのか?この記事はその退屈な半分についてだ。RAGは概念的に理解していると仮定し、Databricksの完全なパスをたどる。チェーンを記述し、MLflowにログを記録し、Unity Catalogに登録し、Model Servingエンドポイントにデプロイし、すべての取得と生成をトレースし、ライブになったらそのものを運用する。
大規模言語モデルは、単純なチャットインターフェースから、計画、推論、外部ツールとの対話が可能な自律システムへと進化しました。この進化の次の段階は、マルチエージェントソフトウェアエンジニアリングであり、単一のモノリシックモデルに依存するのではなく、専門化されたAIエージェントが協力して複雑なビジネスワークフローを解決します。プランナーは作業を分解し、リサーチャーエージェントはエンタープライズナレッジを取得し、コーディングエージェントは実装を生成し、レビューアエージェントは出力を検証し、実行エージェントは承認されたアクションを実行します。このアーキテクチャは魅力的ですが、本番環境へのデプロイでは、複数のエージェントの調整は、プロンプトチェーンの作成よりも分散システムの構築に far more 似ていることが明らかになりました。主な課題は、モデルの知能ではなく、システムの信頼性です。エージェントが追加されるたびに、幻覚、コンテキスト損失、遅延、リトライ、カスケード障害の機会が増えます。個別に高い精度を持つ5つのエージェントを含むワークフローでも、各ハンドオフが不確実性の新たなソースとなるため、一貫性のない結果を生成する可能性があります。したがって、エンジニアリングの課題は、プロンプトエンジニアリングからオーケストレーション、状態管理、レジリエンス、オブザーバビリティへとシフトします。
コンピューティングにおける将来的な賭けであったArm64の時代は、明確に終わりました。Arm64は、組み込みおよび研究中心のアーキテクチャから、Linuxにおける主流のファーストクラスプラットフォームへと移行しました。この変化は、Ampere ComputingのDave Nearyと著名なLinuxカーネルメンテナーであるGreg Kroah-Hartmanとの会話で強調されました。1990年代後半に組み込みシステムでLinuxキャリアを開始したKroah-Hartmanは、Linux開発者コミュニティにおける顕著な成熟を観察しています。当初、Linux開発者は機能を実現するためにUnixのような他のオペレーティングシステムから多大な影響を受けていました。時を経て、Linuxは模倣から革新へと進化し、独自の開発をリードしました。この進歩は、開発者がもはや既存のモデルを再現するのではなく、新しいインフラストラクチャ、インターフェース、およびスケーラブルなプロセスを構築していることを意味します。焦点は、物事を機能させることから、最高水準で構築することへと移行しました。これにより、Arm64は現在のLinux開発、展開、および保守戦略において重要なコンポーネントとなっています。したがって、Arm64は現在、Linuxエコシステムの中核であり、完全にサポートされているアーキテクチャです。
NVIDIAのAIレッドチームは、2026年にエンタープライズAIエージェントの6ヶ月間の評価レビューを実施しました。レビューの結果、失敗したAIエージェントは、アクセス制御の欠如や任意のコードを実行する機能の欠如を含む4つの主な理由で失敗しました。エージェントには、アウトバウンドネットワーキングや分離に関する制限もなく、平文のシークレットが利用可能でした。これらのAIエージェントの問題は本質的にアーキテクチャ的な性質であり、障害に対する防御を困難にしています。モデルのコントロールプレーンは、その統計的な性質から信頼できる防御メカニズムではありません。コントロールプレーンに依存する防御は、悪意のあるアクティビティを正当なものとして偽装することを含む3つの主な方法で回避できます。防御を回避する別の方法として、コマンドの正当性を確立するのに十分な履歴が蓄積されるまで、対話を徐々にエスカレートさせることが挙げられます。3番目の方法には、パッケージのインストールなど、正当な動作にコード実行を埋め込むことが含まれます。レビューの結果は、AIエージェントの障害を防ぐためのより堅牢なセキュリティ対策の必要性を強調しています。全体として、これらの脆弱性の発見は、AIエージェントの安全でセキュアな運用を確保するために、AIエージェントのアーキテクチャ上の欠陥に対処することの重要性を強調しています。
マルチクラウドのピッチは常にクリーンに聞こえる。ベンダーロックインを回避する。特定のタスクに対して最も安価なプロバイダーでワークロードを実行することでコストを最適化する。独立した障害ドメインに分散させることで回復力を向上させる。理論上は説得力のあるケースだ。実際には、マルチクラウド展開で運用しているチームは、しばしばその逆の状態を説明する。運用上の複雑さが倍増し、オブザーバビリティが半減し、1つではなく2つのクラウドが存在することによってのみ発生する信頼性の問題のカテゴリだ。私が密接に協力したチームは、当時のGPUの利用可能性と価格設定の良さから、AWSへのマルチクラウドワークロードとGCPでのML推論パイプラインへの移行を行ったが、その後8ヶ月間、予期せぬインシデントクラスに対処することになった。それはアプリケーションのせいでも、どちらかのクラウドプロバイダーのせいでもなく、それらの境界に存在していた障害だった。負荷がかかったときにのみ現れるデータ転送レイテンシのスパイク。クロスクラウド呼び出し中にのみトリガーされる認証トークンの有効期限のエッジケース。本番稼働前のすべてのテストをパスし、午前3時に本番で失敗するネットワークポリシーの相互作用。個々の問題は難しくなかった。診断ツールがそれぞれ内側を指しており、障害はどちらのツールも見ていない領域に存在していたため、それらは難しかった。
数ヶ月前、私は「Loop Engineering: プロンプト、コンテキスト、ハーネスエンジニアリングの次のレイヤー」という記事で、プロンプトが調整され、コンテキストが組み立てられ、ハーネスが配線された後、エージェントが実際に機能するかどうかを決定するのは、エージェントが実行されるループであると主張しました。つまり、エージェントが継続、停止、再試行、または引き継ぎをどのように決定するかです。その記事の後、数人の読者からもっともな質問がありました。具体的にどのようなループなのか? 1つのジョブが1つのループ分の作業でなくなった場合、何が起こるのか?その質問には、私が答えを探し始めたときにはすでにAIエンジニアリングの世界で形成されつつあった答えがありました。2026年7月中旬、Xでまさにこの件について、OpenClawの作成者であるPeter Steinberger氏からの、会話はすでにループからグラフへと移行したのかという質問をきっかけに、速く、騒がしい議論が行われました。数日後、それは「グラフエンジニアリング」という名前になりました。この記事では、それが実際に何を意味するのか、ループエンジニアリングとどのように重複するのか、そしてその議論における懐疑論者がもっともな点を指摘していたと思われる点について説明したいと思います。