数年前までは、開発者のワークフローにおいて最も強力なAIツールは、コードを書くのを支援するものでした。今日では、彼らはもっと多くのことができる。AIエージェントに次のようなタスクを任せることはますます一般的になっている。
Read this repository, refactor the authentication service to match the new specification, run the test suite, and open a pull request if everything passes.
エージェントは、ファイルを読み込み、依存関係を分析し、コマンドを実行し、コードを変更し、外部システムとやり取りします。多くの場合、最小限の監督で重要なエンジニアリング作業の大部分を完了できる。その変化は漸進的なものに聞こえるが、重要なことに気付くと、私たちはもはや提案を委任しなくなったということに気づく。私たちは業務を委任しています。
興味深いのは、最大の課題が、エージェントがこれらのタスクを実行できるかどうかではなくなってきているということだ。多くの場合、彼らは既にそれが可能だ。より難しい問題は、開発者たちが彼らに重要な仕事を任せるほど信頼しているかどうかだ。ボトルネックは、能力から自信へと移行しつつある。
Srini Sekaran氏が最近発表したDocker AIガバナンスに関する声明を読んでいて、特に印象に残った発言が一つありました。
「あなたのノートパソコンは新しいプロダクションだ。」
考えれば考えるほど、それはマーケティングのキャッチフレーズというより、ソフトウェア開発における変化を理解するための有用な方法のように思えてきた。
アシスタントからエージェントへ
ここ数年の開発者ツールは、進歩の過程と見なすことができる。まず、AIツールは、コードスニペットを生成したり、質問に答えたりすることで、開発者を支援した。その後、コパイロットが登場し、開発者が既存のワークフロー内でより大きなタスクを完了できるよう支援するようになった。今、私たちはエージェントの時代に突入しようとしている。従来のツールとは異なり、エージェントは単にアクションを推奨するだけではありません。彼らはますますそれらを実行に移すようになっている。ソフトウェアが提案を行うのではなく、自ら行動を起こすようになると、ガバナンスに関する議論は根本的に変化する。
エージェントと共に構築する上でのちょっとした考察
AIプロジェクトに取り組み、エージェントベースのワークフローを実験する中で私が気づいたことの一つは、信頼の境界が非常に速く変化するということです。
私がAIツールを使い始めた当初は、それらを主に第二の目として捉えていました。私はコードベースについて質問したり、アプローチの妥当性を確認したり、小さなコードを生成したり、ドキュメントの理解を助けたりします。そのツールは便利だったが、それ自体では何もしてくれなかった。すべての行動は、次に何が起こるかを決めるのは依然として私次第だった。プログラミングエージェントの能力が向上するにつれて、状況は変化した。
以前はウィンドウ間でコードをコピーする作業だったものが、次第にエージェントがリポジトリを検査し、ファイルを変更し、テストを実行し、最小限の監視で不具合を反復的に修正できるワークフローへと変化していった。生産性の向上は紛れもない事実だったが、同時に、エージェントが私と同じ環境、認証情報、ツールにアクセスできるようになったという事実も認識せざるを得なかった。
Dockerキャプテンとして、AIガバナンスに関する現在の議論が私にとって非常に興味深いのは、まさにこの点にある。問題は、単にモデルの性能が向上しているというだけではない。つまり、彼らは孤立したテキストを生成するのではなく、実際のシステムと相互作用する機会が増えているということだ。
代理人があなたに代わって行動を実行できるようになると、課題はもはや能力だけではなくなります。開発者は、エージェントが想定された範囲内で動作するという確信を必要としている。ガバナンスが重要になるのは、システムを保護するだけでなく、人々が利用するシステムを信頼するのに役立つからである。
開発者が依然として躊躇する理由
ほとんどの開発者は、エージェントがコードを生成できるかどうかを気にしていません。彼らは、エージェントが実際のシステムと連携し始めた際に、予測通りに動作するかどうかを懸念している。そうした躊躇は、既存の信頼モデルが自律型ソフトウェアではなく、人間のオペレーターを前提として設計されているという事実から生じることが多い。
ほとんどの企業セキュリティ対策は、比較的単純な前提に基づいて発展してきた。すなわち、人間が行動を起こし、システムがその行動に対する制御を実施するという前提である。ソースコードはリポジトリを経由して流れる。変更はCI/CDパイプラインを経由して反映されます。本番環境のワークロードは、管理された環境内で実行されます。認証システムは、誰が何にアクセスできるかを決定する。ネットワーク制御は、ワークロードが通信できる場所を制限する。セキュリティスタックが機能するのは、作業が通常、予測可能なチェックポイントを通過するからである。組織は、活動を監視し、ポリシーを適用し、監査証跡を収集する場所を把握している。
エージェントはチェックポイントを守らない
AIエージェントは、従来とは異なる運用モデルを導入する。開発者のマシン上で実行されるエージェントは、単一のセッション内で、リポジトリの検査、コマンドの実行、パッケージのインストール、ローカルファイルへのアクセス、APIへのクエリ、外部ツールとの連携などを行うことができます。さらに重要なのは、多くの場合、操作する人物と同じ権限を使用して実行されるということだ。組織の視点から見ると、業務のかなりの部分が、本来組織を統制するために設計されたシステムの外へと移行しつつある。ノートパソコンはもはや、コードを書くだけの場所ではない。そこは、意思決定が実行される場所としてますます重要になってきている。
図1 。従来のセキュリティは、ワークフローのチェックポイントを管理する。エージェントのガバナンスは、実行時における処理を考慮に入れなければならない。
コーディングエージェントは、コードベースとやり取りする前にプルリクエストを待つ必要はありません。変更がリポジトリに反映されるずっと前に、ファイルを分析して変更することができる。ローカル環境で利用可能な認証情報にアクセスできます。オペレーターが利用できる権限と同じ権限を使用して、外部サービスに接続できます。
よくあるシナリオを考えてみましょう。エージェントが、統合テストが失敗する理由を調査するように依頼されたとします。問題をデバッグするために、設定ファイルを検査したり、一時的なスクリプトを生成したり、追加の依存関係をインストールしたり、診断コマンドを実行したり、人間が結果を確認する前にテストスイートを繰り返し実行したりする可能性があります。これらの行動はどれも珍しいものではないが、開発者の環境内で直接どれだけの活動が行えるようになったかを示している。これはエージェントが本質的に危険であることを意味するものではありません。つまり、既存のセキュリティに関する多くの前提を再検討する必要があるということだ。
プロンプトベースのガードレールだけでは不十分な理由
よくある対応策の一つは、指示に従うことである。エージェントに機密ファイルにアクセスしないように伝えてください。担当者に外部サービスに電話しないように伝えてください。エージェントに危険な行動を取らないように伝えてください。これらの指示は役立つが、根本的に執行とは異なる。促しは行動に影響を与える可能性がある。ランタイムは動作を制限することができる。エージェントの自律性が高まるにつれて、その区別はますます重要になる。セキュリティは従来、アプリケーション層よりも下位の層に制御機構が存在する場合に最も強力である。ファイルシステムのパーミッションは、制限を示唆するのではなく、制限を強制するものです。ネットワークポリシーは、トラフィックをブロックすべきかどうかを問うのではなく、トラフィックをブロックする。同じ原則はAIエージェントにも当てはまる。組織がエージェントの能力と限界について確信を持ちたいのであれば、そうした保証は最終的に、実際にアクションが実行される層に存在する必要がある。
エージェントが世界と相互作用する2つの方法
問題を単純化すると、エージェントの活動のほとんどは2つのカテゴリーに分類されます。第一に、実行力です。エージェントは、ファイルの読み取り、コードの変更、ソフトウェアのインストール、コマンドの実行、ネットワーク接続の確立などを行います。2つ目は、ツールの使い方です。エージェントは、API、統合機能、およびMCPツールを介して外部システムと連携します。これらには、GitHub、Jira、クラウドプラットフォーム、社内サービス、コミュニケーションツール、顧客システムなどが含まれる可能性があります。どちらの道も、計り知れない価値を生み出す。どちらの道もリスクを伴う可能性がある。どちらか一方だけを統治すると、盲点が生じる。組織は外部ツールへのアクセスを厳密に管理する一方で、エージェントがローカルで実行できる内容を見落としている可能性がある。あるいは、外部システムへの広範なアクセスを提供しつつ、ローカルでの実行を確実に保護する機能も備えているかもしれない。効果的なガバナンスには、両面における可視性と統制が不可欠である。
ガバナンスの課題
多くの組織にとって、もはやAIエージェントが導入されるかどうかではなく、いかに責任ある形で導入できるかが問題となっている。生産性向上効果が確かなものであるため、世界中のエンジニアリングチームで既にそのような決定が下されつつある。より重要な問題は、組織が可視性、説明責任、および管理を犠牲にすることなく、エージェントの自律性をどのように取り入れることができるかということである。同様に重要なのは、開発者がそれらの境界を理解しているという確信を持つ必要があるということです。エージェントが何にアクセスし、何を実行し、何を変更できるかを理解しやすくなればなるほど、エージェントを日常のワークフローに組み込むことが容易になる。従来のセキュリティモデルは、インフラストラクチャの境界を中心に構築されていた。エージェントのガバナンスには、実行時境界がますます必要となる。
- エージェントはどこで実行されていますか？
- 何にアクセスできるのか？
- どのような処理を実行できるのか？
- どのようなツールを呼び出すことができるのか？
- どの認証情報を使用できますか？
- また、エージェントがラップトップ、CI環境、本番環境のいずれで実行されているかに関わらず、これらの制御を一貫して適用できるのでしょうか？
これらの問題は、単なるAIの問題ではなく、急速にインフラに関する問題になりつつある。AIエージェントがソフトウェア開発において積極的な役割を果たすようになるのであれば、それらが動作する環境は、これまで私たちが本番システムに注いできたのと同等の注意を払うに値する。
ノートパソコンはもはや、ソフトウェア開発のためだけの場所ではない。ますます、そこはソフトウェアが活躍する場所になりつつある。だからこそ、「ノートパソコンは新しいプロダクションデバイスだ」という言葉は、予測というよりは、現代の開発が既に向かっている方向を説明しているように感じられるのだ。真の課題は、単にエージェントにより多くの裁量権を与えることではない。それは、開発者がその自律性を安心して活用できる環境を作り出すことだ。なぜなら、エージェント開発の未来は、エージェントが何ができるかということよりも、開発者がエージェントに何を任せるかをどれだけ信頼するかということに大きく左右される可能性があるからだ。
パート2では、ランタイム層におけるガバナンスのあり方と、分離、ポリシーの適用、制御されたツールアクセスがエージェントシステムの基本的な構成要素になりつつある理由を探ります。
