エージェントは常に新入社員です。設計をそれに合わせる時が来ました。

2027年までに、74%の企業が何らかの形でエージェントを利用すると、最近のDeloitteの調査で予測されています。長年にわたり、私たちはアプリ、ウェブサイト、オペレーティングシステム、文書の操作体験を向上させるためにソフトウェアを設計・構築してきました。今やユーザーは人間ではありません。これは、ダッシュボードや人間のタスク向けに設計した制御されたワークフローからのシフトを超える広範な影響があります。私たちはエージェントの動作環境を設計する必要がある瞬間に直面しており、also 人間のワークフローも設計して、これらの環境内でエージェント体験を効果的に導く必要があります。  

エージェントが繰り返し、確実に成功するために私たちが何を提供すべきかについては、まだ学び始めた段階です。本能的にはエージェント統合を単なるプロンプトや UI の問題として扱いがちです。適切に統治された実行環境の設計は、私たちの文化にとって新しい領域です。しかし、優れた設計と優れたマネジメントの根本原則は変わっていません: エージェントには明確なコンテキスト、曖昧さのない指示、そして明示的な意図を提供しなければなりません。

Context: Why Coding Came First

コンテキストは、エージェントに意図したレベルで繰り返し成果を出させるために最も重要な入力と言えるでしょう。ソフトウェア開発は、リポジトリ、API スキーマ、システム間の関係、コードレビューやコミュニティディスカッションなど、ほぼすべての分野よりも多くの情報が記録されています。したがって、AI フロンティアラボがコーディングから始めたのは理にかなっています。これは、十分なコンテキストがすでに文書化されている数少ない領域の一つです。 

しかし、ソフトウェアチームの新入社員が教えてくれるように、どれだけデータが揃っていても、エージェントは誰も文書化しない暗黙の規則に埋め込まれた組織記憶を欠いています。そのギャップは広範です: 43% の開発者が、AI ツールが自分のプロジェクトやコードベースに関する十分なコンテキストを欠いていることを懸念しています。暗黙知は、特定タスク向けの好みのライブラリといった日常的な慣習から、深刻な運用上の「幽霊」‑ たとえば永遠に残る深夜のホットフィックスや、一見空っぽに見えるデータベース列が実はカスタム収益レポートを支えているといったものまで、さまざまです。このコンテキストはシニアエンジニアの頭の中や最近の Slack スレッド、あるいは全くどこにも存在せず、コードベース自体に記録されていることは稀です。  

もしソフトウェアという最も文書化された分野でさえこうであるなら、エージェントが多くの他業界で即座に効果的に機能しにくい理由が見えてきます。医療や法律の分野では、日々の業務を形作る組織知識の多くが学習と内面化を通じて蓄積されます。これは正式な文書ではなく、人々の経験に宿ります。たとえば法律エージェントは、特定のパートナーが好む構成やトーン、ブリーフの論証方法を知らないかもしれませんし、医療エージェントは忙しい診療所が使用するローカルなワークフローやエスカレーション手順を理解していないかもしれません。文書だけではこのギャップは埋められません。課題は単に情報へのアクセスではなく、コンテキストの転送にあります。エージェントに成功に必要なものを提供するには、新入社員を迎えるのと同様にオンボーディングする必要があります。

Direction: Why Osmosis Doesn’t Work

新しいチームメンバーをオンボーディングするには、適切な資料とアクセスを提供するだけでは不十分です。周囲の成功に投資する姿勢があるとき、私たちは「何をすべきか」についてしっかりとした指示を提供します: 期待値、達成しようとしていることの明確化、そして途中でのフィードバックです。私はこの考え方をエージェント設計にも持ち込みます。タスクに対して具体的かつ明確な指示を与えます（タスクに対する相対的な指示です）。これは在籍期間に関係なく、すべてのチームメンバーに当てはまります。ただし、新入社員シナリオでは、指示はさらに踏み込む必要があります。なぜなら彼らはまだ組織のコンテキストを全く持っていないからです。

エージェントを「決して新入社員であり続ける」新入社員と考えてみてください。エージェントは熱意と能力に溢れ（正直に言うとエネルギーは無限です）、しかし人が時間とともに習得する暗黙の規則を同じように吸収し保持することはできません。人間は浸透と経験で学びますが、エージェントは作業環境に明示的に組み込まれたアーキテクチャから学びます。

新入社員であれば、質問やフィードバック、組織のプロセスや好みについての新たな洞察を通じて時間をかけてギャップを埋められます。文字通りのコーヒーマシンでの会話やチームランチがそれに当たります。エージェントの場合は、そのギャップ埋めを設計自体に組み込む必要があります。具体的には次のような手段が考えられます: 

• 耐久的なルール、タスク固有の事実、関連履歴を分離した構造化コンテキストウィンドウをエージェントに提供し、文書の山を投げ込むのではなく整理する。
• 権限と意思決定の境界を事前に定義する: 何を単独で実行できるか、何が承認を要するか、決してアクセスすべきでないものは何か。
• 強力な出力例をいくつか体験に直接埋め込み、エージェントに「こうすべき」という明確なモデルを示す。
• 過去に遭遇した行き止まり（デッドエンド）を共有する。

適切に統治されたエージェント環境の設計は、モデルの作業を楽にすることが目的ではありません。人間のエンジニアリングチームを見えない技術的負債から守ることが目的です。しかし、方向性が明確でも、エージェントは指示通りに動いても要点を見失うことがあります。指示は「何をすべきか」を伝えますが、「良い」とは何かを示すわけではありません。そのギャップこそが意図（Intent）の出番です。

Intent: Why Agents Drift to The Middle

エージェントは大量の知識で訓練されたパターンマッチングマシンであり、統計的平均を提供する傾向があります。明確で具体的な意図がなければ、エージェントが返すのはまさにその平均的な出力です。たとえば「ユーザー認証エンドポイントを追加して」と指示すれば、エージェントは基本的なパスワードハッシュを備えた教科書的な Express ルートを生成します。動作はしますが、チーム独自の認証サービスを無視し、必須のテレメトリを省略し、標準化されたエラーフォーマットを壊します。紙面上では十分な機能に見えますが、コンテキスト次第では実務上のアーキテクチャ的バグです。このような「バグ」が導入されやすいことは過小評価できません。

これを防ぐには、指示と同時に能動的な意図の検証とロギングを組み合わせる必要があります。ガードレールはコードがコンパイルできるかだけをチェックすべきではありません（それも重要です）。ガードレールは、意見主導の標準、エッジケースのルール、ドメインコンテキストを明示的に強制し、汎用出力を本番レベルの成果物へと昇華させる必要があります。ロギングは人間にとってのシステムステータス指標として重要です。このトレーサビリティが信頼に直結します。 

人間同士のやり取りには不確実性が多く存在します。誰かが最初のバージョンを共有し、共に何が強みで何が改善点かを議論できるのです。これは人間の同僚が自律的な機械であると期待しないから機能します。エージェントという自律的に動く同僚（実際にはもっと自律的に動く必要がある）にその力と約束を本当に活かすには、多くの指向的チェックをエンジニアリングする必要があります。往復のやり取りは依然として必要ですが、すべてを手作業に任せることはできません。明確な受け入れ基準と検証ルールを前もって組み込むことで、エージェントは自ら内部フィードバックループを回すことが可能になります。エラー防止の設計は、この新しい世界で適用できる健全な UX 原則の一つです: エージェントに行動を確定する前に低信頼度をフラグ付けさせ、ベスト推測に黙って委ねるのではなく、警告を出すようにします。

Where the Metaphor Breaks

「新入社員」フレーミングは有効ですが、限界があります。人間の新入社員は経験を積むことで能力が向上し、判断力が養われます。新入社員が「なぜ」コンテキストと指示が重要かを内面化する過程が、時間をかけて信頼を築くのです。一方、エージェントにはそのような経験を蓄積・保存する場所がありません。

新入社員の最初の週と百週目は違いがありますが、エージェントの最初のタスクと千番目のタスクは、何か特別に設計・構築しない限り全く同じです。これが私たちの新たな設計課題です。

Agent Responsibility Hinges on Design

責任がエージェント内部に宿らないのであれば、周囲の土台に宿らせるしかありません。これは、私が新入社員に仕事を任せる前に必ず自問する三つの質問と同じです: どんなコンテキストを持っているか？ どんな指示を与えたか？ 私の意図は何か？

次にエージェントにタスクを任せるときは、出力だけをチェックしないでください。まず自分のインプットを点検しましょう。新入社員が初日に必要とするコンテキストを提供しましたか？ 指示は文字通りに解釈されても耐えられるほど具体的でしたか？ 意図は「中央値の回答」ではなく、可能な限り最良の結果を導くほど明確でしたか？

この明確な指針（バイト単位？）が手元にあれば、興味深いことが起きます: エージェントは長いランウェイを必要とせずに信頼を得られるのです。最初に組み込んだコンテキスト、指示、検証が、すべてのタスクに対する動作を定義します。新入社員は時間をかけて信頼を築きますが、エージェントは設計したシステムを通じて毎回それを獲得しなければなりません。責任は成長して身につくものではなく、最初から組み込まれています。問題はエージェントがいつより大きな責任を担えるようになるかではなく、すべてのタスクでその責任を獲得できるように設計したかどうかです。