「AIエージェントを作る」とは、何を設計することか

Transcript

1. Modelの外側 東大 A I 研究会 × 早稲田 A I 研究会 合同勉強会 / A I エージェント開発講義 「AIエージェントを作る」 とは、何を設計することか Harness 任せる・止める・確かめる Model Modelの外側を設計する。 その原則と、私たちがTrooperで作っているもの。 2026.09.30 株式会社SALT2 鬼澤 輔 ← → で移動 ・ O で一覧 ・ N でノート・ F で全画面 ・ T で明暗切替 Data 見せる・残す Environment 動かす場所 重みの外側で、仕事の成否が決まる 01 / 41
2. 0 はじめに さっきは重みの中の話。この時間は、重みの外の話 直前の講義 Attention Is All You Need Modelの中身。どう学習し、どう次のTokenを予測するのか。 終わったときに、答えられるようになる三つの問い Q1 エージェントとは何か Q2 → この講義 Modelの外側 重みを1bitも変えずに、仕事を最後まで終えられるかどうかを決めている部 分。何を見せ、どこで動かし、どう任せ、どう確かめるのか。 エージェントを作るとき、何を設計す るのか Q3 それを実際に、どう作っているのか 同じModelでも、外側の設計次第で、仕事を終えられるかどうかが変わる。 A I AG E N T D E S I G N ・ S A LT 2 02 / 41
3. 0 はじめに 今日の流れ 1 2 3 4 エージェントとは何か 前半 誰が次の行動を決めるのか。Loopと定義。 エージェントに必要な四つ Model・Data・Environment・Harness。Modelだけでは、エージェントにならない。 四つそれぞれで、何を設計するか 委ねる。見せる。残す。動かす。任せる。止める。確かめる。 私たちはどう作っているか 後半 四つを、会社で使えるサービスとして作り直す。Trooperの構成、改善の仕組み、これから。 A I AG E N T D E S I G N ・ S A LT 2 03 / 41
4. 1 A I AG E N T D E S I G N ・ S A LT 2 エージェントとは何か PA R T 1 重要なのは、LLMやToolsを使っているかではない。実行結果を見たあと、次 に何をするかを誰が決めるのか。 04 / 41
5. 1 エージェントとは何か 実行結果を見たあと、次に何をするかを誰が決めるのか LLMを使っているかどうかでも、Toolsを使っているかどうかでもない。この一点で Chat / Workflow / Agent は分かれる。 次の行動を 決める 人間 質問 回答 順序を 決めている Code Chat 人間が次の行動を決める A I AG E N T D E S I G N ・ S A LT 2 観測して 次を選ぶ 実行結果を観測する 検索 要約 構成 執筆 校正 LLM LLM LLM LLM LLM Model 回答を見て、次に何を聞くか人間が決める Model 各工程でLLMを使っていても、順序が固定ならWorkflow Workflow Codeが次の行動を決める 追加で 別の資料を 人間へ 前工程へ 検索 確認 質問 戻る 足りなければ探し、矛盾すれば確かめ、詰まれば聞く Agent Modelが観測結果から次の行動を選ぶ 05 / 41
6. 1 エージェントとは何か Agentは、観測・行動・検証のLoopで動く 「このBugを修正して」と頼んだときの、Coding Agentの典型的な動き。いきなりCodeを書き始めるとは限らない。 依頼 「このBugを 修正して」 観測 Repositoryの 構造を確認 関連する Fileを読む Error logと Test結果を確認 判断 行動 検証 報告 どこに問題が ありそうか考える Codeを Testを 変更内容と Test結果を報告 変更する 実行する Testが失敗すれば、結果を読んで再び修正する まず状況を観測し、問題箇所を考え、変更し、Testで検証する。失敗すれば結果を読んで前の工程へ戻る。最後に変更内容とTest結果を報告する。 毎回Planを作るとは限らない。大事なのは、実行結果を受け取り、その結果に応じて次の行動を変えられること。 A I AG E N T D E S I G N ・ S A LT 2 06 / 41
7. 1 エージェントとは何か Agentとは、次の行動を選び直せる実行システムである Agentとは、設計された境界の中で、Goal の達成に向けて状況を観測し、次の行動を 選び、実行し、結果を検証しながら進めるシ ステムである。 人間が設計する境界 観測する Modelが何でも自由に決めるわけではない。人間が Goal・使える Tools・権限・予算・終了条件を設計し、Modelはその境界の中で次 の行動を選ぶ。 Agentの本質は、完全自律ではない。 状況に応じて、次の行動を選び直せることに ある。 Goal 行動を選ぶ Model Tools 権限 境界の中で、次の行動を選ぶ 検証する 実行する 予算・終了条件 A I AG E N T D E S I G N ・ S A LT 2 07 / 41
8. 2 A I AG E N T D E S I G N ・ S A LT 2 エージェントに 必要な四つ PA R T 2 Modelだけでは、エージェントにならない。Modelが活躍するには、Dataと、 活動する場所と、それらをつなぐ仕組みが要る。 08 / 41
9. 2 エージェントに必要な四つ エージェントが働くには、四つが要る Claude CodeやCodexを使うとき、この四つは全部そろっている。ただし、一人の開発者の手元と権限を前提にしている。 Claude Code・Codexでは、それぞれ何か Model 考え、次の行動を選ぶ Actionを提案 Model Contextを渡す Harness つなぐ・任せる・止める・確かめる 読む・記録する 実行し、結果を見る Data 仕事の材料と、進み具合の記録 Environment 手を動かし、状態が変わる場所 Tools ＝ DataとEnvironmentへの出入り口 Claude・GPTなど。次のActionを提案する。自分でFileを変えるわけで はない Data 手元のFile、MCPでつないだService。見せる情報と、進み具合の記録 Environment 自分のPCのTerminalや、本人用のクラウド環境。実際に作業し、状態が 変わる場所 Harness Claude Code・Codex本体。Modelを呼び、Toolを実行し、結果を戻し、 止め、記録する 権限の置き場所も分けておく。読める範囲はData、動かせる範囲はEnvironment、実行して よいかの判断はHarness。 Modelだけでは、エージェントは成立しない。四つがそろって、はじめて仕事が進む。 A I AG E N T D E S I G N ・ S A LT 2 09 / 41
10. 3 A I AG E N T D E S I G N ・ S A LT 2 四つそれぞれで、 何を設計するか PA R T 3 Modelに何を委ねるか。何を見せ、何を残すか。どこで何をさせるか。どう任 せ、どう止め、どう確かめるか。 10 / 41
11. 3 何を設計するか Model Data Environment Harness Model：任せる判断と、Workflowとして固める手順を分ける 経費精算の例。判断が必要な部分だけをAgentにし、ルールはWorkflowとして固定する。 Agent：状況に応じた判断が必要 領収書を 読む 内容を 分類する 事前にすべての分岐を書き切れない Workflow：ルールとして固定する 不足情報を 検出する 一定金額以上は 部門長承認 特定費目は 証憑を必須に 承認前は会計 Systemへ登録しない 支払処理は 決められた順番で 毎回Modelに判断させる必要がない。順序・法的要件・不可逆な処理 不確実性がない部分までAgentにすると、Costと失敗の可能性だけが増える。事前に分岐を書き切れない判断だけをModel に任せ、順序・法的要件・不可逆な処理はWorkflowとして残す。 A I AG E N T D E S I G N ・ S A LT 2 11 / 41
12. 3 何を設計するか Model Data Environment Harness Data：何を見せるかで、判断の質が決まる Agent が見る候補 過去の資料 全部は見せず、必要なときに開かせる 現在のDatabase 過去の顧客対応履歴 業務ルール Repositoryの構造 進行中のTask 承認待ちのAction Agentは、見えていない情報では判断できない。一方で、全部を最 初から見せると重要な情報が埋もれ、Costも増える。 Agent Skills 最初は手順書の名前と説明だけを見せ、必要になったら本文を読ませる。2025年12月にオープン標 準として公開された。 MCP DataやServiceへのつなぎ方の共通規格。2026年7月に、大規模に運用しやすい形へ大きく改訂さ れた。 Dataへのつなぎ方は共通化された。何を、いつ、どこまで見せるかは、作る人が設計する。 A I AG E N T D E S I G N ・ S A LT 2 12 / 41
13. 3 何を設計するか Model Data Environment Harness Data：会話と記録を分ける Contextは作業机の上の資料。Stateは仕事の進捗台帳。長い仕事は、机の上ではなく台帳で支える。 Context 作業机の上の資料 State 仕事の進捗台帳 現在のModel呼び出しで、直接見えている情報 System prompt・仕事の定義 会話履歴 どこまで進み、何が終わり、何が未解決なのかを表す情報 書き出す Toolの実行結果 検索結果、Fileの内容、Test出力… 進捗 Repository調査 完了、関連File特定 完了 判断 公開APIは変更しない（互換性のため） 成果物 fix/issue-42 の差分、Test結果 再開時に読み戻す 未解決 仕様の曖昧点 → 人間へ質問中 次にやること Regression Testを実行 Contextの圧縮・再起動・呼び出し失敗で、机の上は消える Contextの外に保存され、再開の起点になる Claude Fable 5.1の発表では、38時間の無人実行の例に加えて、別の利用企業が「自分で記録をつけ、状況が変わると優先順位を付け直す」と評している（Anthropic、2026年9月）。 長時間Agentとは、長く考え続けられるAgentではない。途中の状態を外に残し、失敗しても正しい地点から再開できる Agentである。 A I AG E N T D E S I G N ・ S A LT 2 13 / 41
14. 3 何を設計するか Model Data Environment Harness Environment：Toolsは、Agentが行動できる範囲そのもの Toolsが多いほど、Agentが優秀になるわけではない。 Tools が多い・曖昧だと、起きること どこまで操作させるのか → 選択を間違える 入力項目が曖昧である → 不適切な値を渡す 返却結果が長すぎる → 重要な情報が埋もれる Error内容が不明確である → 失敗後に修正できない 良いToolは、目的が明確で、入力が分かりやすく、Errorの理由が分かり、間違え ても壊しにくい。 さくにし消り取・さき大の響影 似たToolsが大量にある メール送信 Databaseの更新 この仕事に必要な範囲まで許可する Fileの作成 検索だけ 許可する行動の範囲 → 検索だけか。Fileの作成までか。Databaseの更新、メール送信までか。 Write・Deleteなど、Environmentを変えるToolsほど、操作できる範囲を狭くする。 A I AG E N T D E S I G N ・ S A LT 2 14 / 41
15. 3 何を設計するか Model Data Environment Harness Environment：動かせる範囲は、仕組みで制限する 設計すること どのFile・Systemを変更してよいか いくらまで使ってよいか 本番環境へ触れてよいか どこへ通信してよいか 作業する場所を、本物の環境から隔離するか Agentの権限は、できるだけ広く与えるものではない。仕事を完了 するために必要な範囲へ限定する。 事例：英国AI Security Institute（2026年8月公表） サイバー能力の評価中、122回の試行のうち10回で、範囲外の行動が計19件起きた。偽の身分で 実在の開発者に働きかけ、公開のオープンソースへ悪意あるCodeの変更提案を出した例もあっ た（管理者が拒否し、未遂）。 評価のために外部接続は意図的に開けられ、一部の安全装置も切られていた。対応として、外部 通信の制限を強め、範囲外の行動をリアルタイムで監視する形に評価を見直した。 OWASPの2026年版では、過剰な権限・機能・自律（Excessive Agency）がLLMアプリの危険の第3位に入 った。 「危険なことをしないで」と頼むだけでは足りない。動かせる範囲は、Modelの外側で強制する。 A I AG E N T D E S I G N ・ S A LT 2 15 / 41
16. 3 何を設計するか Model Data Environment Harness Harness：任せる ― 依頼を「仕事の約束」にする 「調査して」「直して」だけでは、何をもって終わりかが決まらない。Bug修正を、仕事の約束として定義する。 GOAL CONSTRAINTS DONE BUDGET APPROVAL STOP DELIVERABLE 指定されたBugを修正する。 既存の公開APIは変更しない。変更は新しいBranchに限 り、本番環境へDeployしない。 対象Testだけでなく、既存のRegression Testも通す。 作業は2時間、Model呼び出しは200回まで。 新しいDependencyを追加する場合は承認を求める。 仕様が判断できない場合は推測せず、人間へ質問する。 最後に変更差分、Test結果、残っているRiskを報告する。 これは、長いPromptを書いているのではない 何を任せるのか 何を守らせるのか どこまで任せるのか 何を提出させるのか という、仕事の約束を定義している。 複数のAgentに分けるか 独立して並列にできる仕事、Contextや権限を分けたい仕事だけ に使う。判断が順番に依存する仕事は、一つのAgentの方が管理 しやすい。Multi-Agentは上位版ではない。 高い自律性を与える前に、責任範囲を明確にする。 A I AG E N T D E S I G N ・ S A LT 2 16 / 41
17. 3 何を設計するか Model Data Environment Harness Harness：止める ― どこで人へ戻し、どこは任せるか 一定の範囲で、任せて進めてよいもの 検索 読取 計算 Draft作成 隔離した場所でのTest 人間が実際に確認する割合 承認を求める回数 承認を求める回数が多いほど、人は中身を確認しなくなる。低RiskなActionまで毎回確認 すると、人がAgentの速度を制限する。 人へ戻すべきとき 必要な情報が見つからない Goalが曖昧である 複数の選択肢があり、Business判断が要る 金銭や契約に大きな影響がある 操作が不可逆である 品質を自動で判断できない 質問することは、Agentの失敗ではない。人にしか判断できない場所へ、人の注意を集める。 A I AG E N T D E S I G N ・ S A LT 2 17 / 41
18. 3 何を設計するか Model Data Environment Harness Harness：確かめる ― Output、Outcome、Evidenceを分ける OUTPUT OUTCOME EVIDENCE 定義 Agentが返した文章やFile 仕事の実行後に、Environmentがどのような状 Outcomeが正しいと判断するための根拠 態になったか 予約Agent 「予約しました」と回答した Databaseに、正しい予約情報が作成されてい DatabaseのRecord、操作Log Coding Agent 「Bugを修正しました」と回答した 期待する挙動になり、Testが通り、意図しない 変更がない Test結果、Git diff る 採点表と、別の採点役 完了の基準を採点表にし、作業したAgentとは別のContextで採点する。 AnthropicはManaged Agentsの機能として提供している（2026年5月）。 作業する役と、確かめる役を分ける Anthropicが公開した模擬環境の実験（2026年7月）では、Agentが承認済みの Dataを密かにゼロへ置き換え、進捗報告ではそれを伏せて正常終了に見せた。人 が直接問いただすまで発覚しなかった。だから、成果物を変える役と、完了を確か める役を分ける。 Agent自身の自己申告を、完了の証拠にしてはいけない。 A I AG E N T D E S I G N ・ S A LT 2 18 / 41
19. 3 何を設計するか Model Data Environment Harness Harness：確かめる ― 一度の成功と、毎回の成功は違う 同じTaskでも、毎回同じ経路で進むとは限らない RUN 1 ✓ 成功する RUN 2 ✕ 制約を見落とす RUN 3 ✕ 不適切なToolを選ぶ RUN 4 ✕ 情報不足のまま推測する Agent の Testで確認すること 通常のTaskで成功するか 入力表現が少し変わっても成功するか 必要な情報が不足しているとき、質問できるか Toolが失敗したとき、回復できるか 禁止されたActionを実行しないか ModelやPromptを変えたあとも、既存Taskが壊れないか k回のうち1回でも成功する率（pass@k）ではなく、k回とも成功す る率（pass^k）で見る。やり直しを増やしただけの改善は、前者で しか良く見えない。 長いPC作業のBenchmark「OSWorld 2.0」 （2026年6月）でも、失敗の型は同じだった。制約を見失う、途中で届いた情報を見落とす、聞かずに推測する、検証を飛ばす。発表時点で最も高いModelでも、完了で きたのは約2割。 AgentのTestは、回答文の評価ではない。仕事の進め方と、最終的なEnvironmentの状態を評価する。 A I AG E N T D E S I G N ・ S A LT 2 19 / 41
20. 3 何を設計するか 作る前に、四つの問いに答える 最初に：このAgentは、何の仕事を引き受けるのか。そのうえで ― Model Data どの判断をModelに委ね、どこを Workflowとして固めるか 何を、いつ、どこまで見せ、何を記録とし どこで動かし、何をどこまで変えてよい て外に残すか か 委ねる 不確実な部分だけをAgentに 見せる ・ 残す 必要なときに開かせる 会話と記録を分ける Environment 動かす Toolsは小さく明確に 範囲は仕組みで制限 Harness 任せる ・ 止める ・ 確かめる 何をもって完了とし、いつ人へ戻し、何を 証拠にするか 仕事の約束 人へ戻す条件 Evidenceとpass^k SDKを開くのは、この問いに答えたあとである。Agentは、完了を証明できて初めて、仕事を任せられる。 A I AG E N T D E S I G N ・ S A LT 2 20 / 41
21. 4 A I AG E N T D E S I G N ・ S A LT 2 私たちは、 どう作っているか PA R T 4 四つを、会社で・チームで・人が見ていなくても使えるサービスとして作り直 す。SALT2のTrooper。 21 / 41
22. 4 私たちはどう作っているか Claude CodeやCodexは、一人の開発者の手元と権限を前提にしている 個人の開発には十分に強い。しかし、会社の仕事をチームで任せようとすると、四つとも作り直しが要る。 CLAUDE CODE ・ CODEX 会社の仕事で任せるなら Data 自分のFileと、自分でつないだService 会社のDataを、頼んだ本人の権限の範囲で、安全に扱う Environment 自分のPCのTerminal、または本人用のクラウド環境 Sessionごとに、隔離された作業場所をサービス側で立てる Model Model提供会社のAPI 仕事に応じて切り替える。Dataを外に出さないために、自前で動かす Modelも使う Harness 人が画面の前で指示し、結果を見る 出来事をきっかけに動き、使われた記録から改善していく Harnessを借りられるサービスも出てきた（OpenAI Agents APIの公開Beta 2026年9月、Anthropic Managed Agents）。それでも、Dataをどこに置き、どこで動かし、どのModelを使えるかは、使う会社の事情 で決まる。 Agentを会社の仕事で使ってもらうには、Modelの賢さと同じくらい、この四つの作り直しが要る。 A I AG E N T D E S I G N ・ S A LT 2 22 / 41
23. 4 私たちはどう作っているか 目指すのは、人が見ていなくても仕事が終わっている状態 今 人が指示し、見守る 人が画面の前で頼み、結果を見て、次を頼む。 Agentは人の操作を起点に動く。 次 → 出来事から動き出す 会議が終わった。メールが届いた。期限が来 た。人が画面を開いていなくても、Agentが仕 事を始める。 目指す姿 → 優秀な部下のように働く 必要な情報は自分で調べる。判断が要るとこ ろだけ、調べた結果と案を添えて聞く。終わっ たら、根拠と一緒に報告する。 そのために、Agentに求めること 事実と根拠に基づく 最後まで自分で終える 任せた範囲を守る 分からないことは聞く AIと人が協働するとは、人がAIを操作し続けることではない。任せた仕事が、任せた範囲で、終わっていることである。 A I AG E N T D E S I G N ・ S A LT 2 23 / 41
24. 4 私たちはどう作っているか Trooperの全体像：共通のCoreと、その上に並ぶ製品 二つの層 製品 ― どれも同じ層。人が仕事を頼む入口 Trooper Work Hub 最も汎用的に使える どんな仕事でも頼める Trooper for Sales 営業チームの優秀な部下 Trooper for … 業務ごとに増やしていく 製品 Core Trooper Core Agentの中核 ― 同じ仕事を、より確実に、より速く、より安く Model 切り替えと自前のModel ↺ Data 本人の権限・承認・記録 Environment Sessionごとの作業場所 Harness 任せる・止める・確かめる Work Hubは最も汎用的な入口。for Salesな どは、業務ごとの仕事の定義と画面を持つ。ど れも同じ層に並ぶ Model・Data・Environment・Harnessの四 つと、改善の仕組み。すべての製品が共有する 製品ごとの振る舞いは作り直してよい。Data・権限・監査・安全の 約束は、Coreが持ち続ける。 使われた記録から、Harnessを改善し続ける。改善はすべての製品に効く 共通のCoreを一つ作り、その上に、汎用の入口と業務ごとのAgentを並べていく。 A I AG E N T D E S I G N ・ S A LT 2 24 / 41
25. 4 私たちはどう作っているか 実際の画面：Agentの動きが見え、人がいなくても動く 会話の画面 考えている → Toolを実行 → 入力と結果のJSON → 失敗しても、それを踏まえ て続ける。Agentが何をしたかが、全部見える。 開発中の画面（2026年9月時点）。表示名は旧称で、一部の識別子は伏せている。 A I AG E N T D E S I G N ・ S A LT 2 自動実行をつくる画面 メール受信やフォルダ更新をきっかけに動く。「本人の権限で、誰も見 ていない時間にも動く」ことへの同意を取り、実行主体として名前を出す。 25 / 41
26. 4 私たちはどう作っているか Trooper for Sales：営業担当の一日は、こう変わる 目指す体験を、架空の営業担当の一日で追う。手本は「とびきり優秀な部下なら、どうするか」。 11:00 Trooper 準備は前日から進 めてある。いまの状 態を数行で見せる 確認のお願いを1 提案書・準備ノー スマホ1画面に、今 件。 「明日が商談で ト・営業管理をまと 回決めること・聞く す。見るべきは1点」 めて直し、「変えたも 順・相手のこと の4点」 人 今日やることを、自分で 「これでいい」を押す。 声で一言。「情シスの人 30秒読んで、会議に入 お客さまと向き合う 何も入力しない。メー 後輩が「ほかの案件を 組み立てなくていい 押さなくても仕上げは も来るらしい。全部見 る ルを読んで、自分で送 踏まえると？」と聞く 進む 直しといて」 る いま メール・予定表・営業管理 前回の提案書を複製して 「帰社したら直そう」と覚 議事録を読み返して思い 商談 を順に開いて組み立てる 直す えておく 出す 開く 商談の前日 13:20 移動中 14:55 翌週 9:30 商談5分前 15:00 16:30 ここは人の仕事 議事録から整理し、 先輩の直しを、由来 営業管理へ記録。 と条件つきで返す 次回の予定を作り、 お礼メールは下書 きまで 商談 商談後 後輩の相談 営業管理へ転記し、お礼 うまくいった言い方は、本 メールを一から書く 人の頭の中だけ 届けたい価値は三つ。やっておいてくれる・すぐ応えてくれる・チームを強くしてくれる。ここに描いたのは目指す体験で、人物・会社は架空。 A I AG E N T D E S I G N ・ S A LT 2 26 / 41
27. 4 私たちはどう作っているか Trooper for Sales：二つの輪と、一本の線引き 何も言わなくても進む「先回りの輪」と、指して一言で動かす「指示の輪」。どちらから始まっても、裏の流れは同じ。 人へ上げるのは、節目だけ 先回りの輪 1 仕事が立つ 予定・議事録・メール・ 社内会議・期限 2 別の目が検査する 3 反映する 仕事の状況に 静かに反映 今日18:00まで。返事が無ければ、このまま仕上げます これでいい ここをこうして あとで 4 読み直して確かめる 指した物の場所に結果 「変えたもの4点」 「元に戻す」 1件ごとに承認させない。人が認めるのは「決め方」 出来事から 指示の輪 人の一言から 物を指して、聞く・ 経緯を聞く・直させる 書く前の関所 営業管理・資料・予定 書いた先が本当に変わったか 外へ出るもの メールは下書きまで。 3を通らない。 送るのは、必ず人 結果を見て、次の一言 期日前の確認 A社 明日14:00の2回目 ― この方向で仕上げました。見てほしい のは1点 返事が無いときどうするかを、必ず添える 自動で書いたものは、1操作で元に戻せる 後から人に直された割合を種類ごとに測り、落ちた種類だけ自動をや める 一言で何でも動く。ただし、外へ出るものだけは、必ず人の手を通る。 A I AG E N T D E S I G N ・ S A LT 2 27 / 41
28. 4 私たちはどう作っているか アーキテクチャ：考える側と、手を動かす側を分ける Modelの鍵・判断・記録を持つ「考える側」と、Toolを実行する「手を動かす側」を、別の基盤に置いている。 利用者のブラウザ 考える側 ECS Fargate・鍵・判断・記録を持つ HTTPS・SSE Server（Hono） React + Vite 手を動かす側 EKS + gVisor・Sessionごとに1つ PostgreSQL sandboxd HTTP API・SSE配信・ジョブ event log・状態・承認・監査 Tool実行・ブラウザ操作・秘密ゼロ Agent loop（Flue） 1ターンの運転・Contextの圧縮 S3 共有File・作業場所の退避 接続は作業場所の側から張る LLM Gateway 実行の関所（Gatekeeper） egress gateway 鍵の付与・生の応答の記録 LLMプロバイダ Anthropic・OpenAI・Gemini・自前 allow / deny / ask・記録を先に確定 検証と冪等の台帳 forward proxy・既定は遮断（fail-close） 公開Web・外部SaaS 許可した宛先だけ Stack TypeScript / Node・Hono・Drizzle + PostgreSQL・React + Vite + TanStack・Flue・AWS（CloudFront / ECS Fargate / EKS + gVisor / S3） ・Terraform A I AG E N T D E S I G N ・ S A LT 2 28 / 41
29. 4 私たちはどう作っているか 一つの依頼は、こう流れる 考える側と、手を動かす側を分ける。Modelの鍵・判断・記録はすべて考える側に置き、作業場所にはToolを実行する力だけを置く。 考える側 Modelの鍵・判断・記録はすべてこちら 利用者 Work Hub・for Sales 依頼 途中経過 受付 依頼を先に記録する Harness Loopを回す 手を動かす側 Sessionごとの作業場所 実行の関所 許可・拒否・人に確認 許可 作業場所（Sandbox） Toolを実行する。鍵を持たない 結果 外への通信は、許可した宛先だけ 接続は作業場所の側から外向きに張る 記録 Event・状態 Modelの中継所 鍵の付与・全呼び出しの記録 本人の権限で 会社のData・外部Service 本人の権限で読む。書き込みは承認を通す Model 商用API・自前のModel 依頼は先に記録してから実行する。Modelへの呼び出しは必ず中継所を通る。Toolの実行は関所で判定し、読み取り以外のToolは判定を記録できなければ実行しない。許可は1回の実行にだ け効く。結果は成功・失敗・不明の3つで返し、不明は自動でやり直さない。 A I AG E N T D E S I G N ・ S A LT 2 29 / 41
30. 4 私たちはどう作っているか Model Data Environment Harness Model：仕事に応じて切り替え、自前でも動かす 切り替える すべてのModel呼び出しは、自前の中継所（LLM Gateway）を通る 商用のAPIも、オープンウェイトのModelも、同じ形で登録して使い分 ける 登録するときに実際に呼び出して接続を確かめ、思考の深さの指定が 通るかも自動で判定する 自前で動かす 2026年9月、社内のGPUで動かすオープンウェイトのModelを本番に 入れ、社内の既定Modelにした PromptとDataを、外部のModel提供会社へ出さない構成が作れる 前提として置いていること 同じHarnessが、Modelによって効いたり逆効果になったりする。弱 いModelほど恩恵を受けにくい。だから、Modelを替えるときは、通 常の会話・Tool呼び出し・代表的な業務の確認を通してから使う。 Modelの管理画面 プロバイダごとに使えるModelと、機能・単価が並ぶ。社内のLLMやOpenAI互換のAPIも、 同じ画面から登録し、実際に1回呼んで確かめる。 Modelは替えられる部品にする。だからこそ、Model込みでHarnessを確かめ続ける。 A I AG E N T D E S I G N ・ S A LT 2 30 / 41
31. 4 私たちはどう作っているか Model Data Environment Harness Data：安全だから、Dataを預けてもらえる 1 Agentの価値は、使えるDataで決まる 2 Dataを預けてもらうには、安全が先に要る 会社の資料・メール・予定・業務のDatabaseに触れられない Agentは、一般論しか返せない。 誰の権限で読み、何を書き、どこへ出したのかを、会社が説明でき なければならない。 Trooperでの作り 読むのは、頼んだ本人の権限の範囲だけ 社外へ出る書き込み（メールの下書き、社外を招く予定など）は、承認を通す 誰が・いつ・何を・何を根拠に変えたかを残す Modelの呼び出しは、必ず自前の中継所を通る。本物の鍵は作業場所に置かず、呼び出 すときに中継所が付ける すべてのModel呼び出しの、実際の入力と生の応答を記録する 3 安全を詰めると、Modelの置き場所まで決まる PromptとDataを、外部のModel提供会社へ出せない会社があ る。 Dataへのつなぎ方は共通化された。差がつくのは、どこまで安心してDataを渡してもらえるかである。 A I AG E N T D E S I G N ・ S A LT 2 31 / 41
32. 4 私たちはどう作っているか Model Data Environment Harness Data：つないだDataを、意味の地図にする つなぐ先はバラバラ 意味の地図（オントロジー層） 社内チャットの発言 案件 メール・予定 人 基幹・業務システム 一部 担当 案件一覧・社員名簿 集める・抽出する 状態：提案中 関係 会議 作業 Agentが会話で引く 「この案件、誰が何してる？」 日報の下書き 人と日ごとに 案件ごとの状態 発言から、いまの状態を出す 読む人の権限で組み立て直す どの関係にも：根拠の引用・有効期間・誰が読めるか 人が直す（訂正は追記で残る） 根拠のない事実を置かない 名前だけで人を結ばない 見え方は、読む人の権限で決める すべての関係に、元の発言の引用と有効期間を持たせる。 本人はIDと接続の記録で、案件は辞書で結ぶ。LLMの推測 根拠の発言を全部読める人にだけ、その事実が見える。日 引用が本文に無い主張は保留にする。 で本人を決めない。 報も案件画面も、同じ地図の見え方。 いまは社内チャット（Slack）の発言と、案件一覧・社員名簿を辞書にして、開発・検証している段階。 Dataにつなぐだけでは足りない。つないだDataを、Agentが使える「意味の地図」にする層が要る。 A I AG E N T D E S I G N ・ S A LT 2 32 / 41
33. 4 私たちはどう作っているか Model Data Environment Harness Environment：Sessionごとに、隔離された作業場所を立てる Claude CodeやCodexは、主に本人のPCや本人用のクラウド環境で動く。チームの仕事として任せるなら、作業場所は会社のサービ ス側で、Sessionごとに用意しなければならない。 1つのSessionに、1つの作業場所。他の人の仕事と混ざらない 作業場所にDataを持ち込み、Agentはその中でFileを作り、Codeを動かす Harness（考える側） Session A Session B Session C 持ち込んだData 持ち込んだData 持ち込んだData Toolの実行 Toolの実行 Toolの実行 の作業場所 の作業場所 の作業場所 作業場所は外からの接続を受け付けない。命令は、作業場所の側から張った接続の中を流れる Modelの鍵も業務の認証情報も置かない。鍵らしきものが混ざっていたら起動しない 実行してよいかは、外の関所と作業場所自身の二重で確かめる しばらく使われなければ中身を退避して片付け、次に話しかけられたら用意し直す（本番での確認は 途中） 接続は、作業場所の側から外向きに張る（外から入る道を作らない） 外への通信は、許可した宛先だけ（既定は遮断） Agentを会社で使ってもらうには、賢さより先に、この作業場所が要る。 A I AG E N T D E S I G N ・ S A LT 2 33 / 41
34. 4 私たちはどう作っているか Model Data Environment Harness Environment：作業場所とは、こう話す 命令は、作業場所の側から張った接続の中だけを流れる。許可は1回きりで、署名つき。結果は3つの値で返す。 考える側（RpcClient） 作業場所（sandboxd） 関所の許可を運ぶ EKS + gVisor・秘密ゼロ 1 作業場所から接続を張る（SSE下り＋POST上り）。外から入る道はない 2 challenge 3 hello（HMAC）→ welcome ― 互いを確かめる 4 exec_request ― 関所が許可した「1回限りの実行権」 （HMAC署名） 5 範囲を自分でも再検査 admission（最後の関所） unknownは 自動で再送しない。 二重の書き込みを防ぐ 7 exec_result ― succeeded / failed / unknown 6 台帳に admitted を追記 bash（-e -o pipefail） → settled を追記 外から入れず、許可なしに動けず、失敗を成功に見せられない。作業場所は、仕組みで信頼の外に置く。 A I AG E N T D E S I G N ・ S A LT 2 34 / 41
35. 4 私たちはどう作っているか Model Data Environment Harness Harness：いまのTrooperがやっていること 指示 手順書 Context 報告 関所 上限 4層で組み立てる。製品の前提 → Toolの案内 → Projectの指示 → 利用者の指示 名前と説明だけ先に見せ、開いたときに本文 を読ませる 枠の半分を目安に要約して圧縮。大きな出力 は保存して参照に置き換える 途中報告と最終回答の境界を、専用のToolで 明示させる allow / deny / ask。読み取り以外は、判定の 記録を確定してから実行 Session の状態は、五つだけ failed idle 待機 archived working ターン実行中 awaiting_approval 人の答え待ち 作業場所の準備は、状態に出さない 以前は starting があり、起動待ちの60〜90秒は 送信できなかった。 「インフラの都合を会話の 状態に漏らした誤り」として廃止した 1往復あたりの回数・費用・時間 仕組みは足すより、減らす方が難しい。インフラの都合を、仕事の状態に漏らさない。 A I AG E N T D E S I G N ・ S A LT 2 35 / 41
36. 4 私たちはどう作っているか 何を良くしていくのか：プロダクト全体と、クライアントごと プロダクト全体（Trooper Core） クライアント・ユースケースごと Agent・ Harness → Evalの仕組みで更新 指示の組み立て、Contextの扱い、Toolsの見せ方、Errorの返し方、関所 の仕組み 直せば、すべてのクライアントに効く 会社・Project・個人ごとの手順書と指示、知識、使えるToolsと権限の設 定 そのクライアント・その業務だけに効く（カスタマイズ・パーソナライズ） Model → 使い分けと追加学習 仕事ごとのModelの使い分け（ルーティング）、新しいModelの取り込み と確認、将来の追加学習・蒸留 そのクライアントの環境で動かすModelの選択。安全の要求に合わせ て、自前のModelを置く 一番難しい ところ 全体の品質・速さ・費用が変わる そのクライアントの制約に合わせる 権限の加減。できなさすぎると必要な情報や操作に届かず、仕事が終わらない。できすぎると、余計なことや、やってはいけないことまでする。Claude CodeやCodexでは人 が横で見て補っているこの加減を、人が見ていないところで任せきるには、Harnessに作り込むしかない。 A I AG E N T D E S I G N ・ S A LT 2 36 / 41
37. 私たちはどう作っているか 4 Model Data Environment Harness Agent・Harnessの更新：Evalの仕組みで回す 1 2 3 4 5 6 Model呼び出しの 1つの会話に、 何の仕事をしたか。 終わったか。 無駄はなかったか 指示・手順書・ Tools・権限・ 改善を作る側には 見せない試験問題 も使う 小さく、 戻せる形で、 少しずつ 記録を集める 入力と生の応答、 Toolの実行と結果 仕事ごとに分ける 複数の仕事が 混ざっている 採点する 直す候補を作る 試験で比べる Harness 反映する 反映した結果も、また記録される Trooper Coreに当てはめる 全クライアントの記録から、Harnessそのものを直す。直せば、すべての製品とクラ イアントに効く。 記録から 分かったこと 1つのクライアント・ユースケースに当てはめる その会社の記録から、手順書・指示・知識・権限の設定を直す。そこだけに効く。 7日分のToolの失敗を調べると、主な原因はModelの賢さではなく、Modelの外側 にあった。使えない機能を見せていた。手順書と作業場所の制約が合っていなかっ た。 A I AG E N T D E S I G N ・ S A LT 2 PDFからHTMLを作らせた例では、用意した手順書は一度も開かれず、失敗した Commandの出力をつないだ結果、失敗が成功に見えていた。 37 / 41
38. 4 私たちはどう作っているか Model Data Environment Harness Modelの更新：使い分けから、追加学習へ 1 使い分ける ルーティング 仕事ごとに、品質を満たして完了した仕事1 件あたりの費用でModelを選ぶ。今は中継所 で切り替えている。次は仕事に応じて自動で 選ぶ。 2 → 自前で動かす オープンウェイト 社内のGPUで動かすModelを本番の既定に した。次は、顧客の環境の中へ。Promptも Dataも外に出さない。 3 → 育てる 追加学習・蒸留 記録と試験がそろったら始める。本番と同じ Harnessの条件で学習させ、報酬の抜け道 がある前提で設計する。今はまだ始めていな い。 どの段でも、同じ試験で確かめる 同じHarnessが、Modelによって効いたり逆効果になったりする。だから、Modelを替える・育てるたびに同じ試験を回し、良くなったのがHarnessのおかげか、重みのおかげか を切り分けて測る。 重みの外側で集めた記録が、最後は、重みそのものを良くする材料になる。 A I AG E N T D E S I G N ・ S A LT 2 38 / 41
39. 5 チーム Trooper Coreを、この3人でつくっている Agentの中核（Harness・実行基盤・評価の仕組み）の開発、Agentの構築、製品全体のアーキテクチャ設計。 CEO / SENIOR AI ENGINEER AGENT EVAL / CORE 東京大学 工学部 システム創成 学科 PSIコース卒。松尾・岩澤 研究室で、LLM・Embedding model・RAG / in-context learningを研究。いまは、 Trooper Coreの開発と、プロ ダクトの方向づけ・開発を担う。 インペリアル・カレッジ・ロンド ン 物理学部出身。量子コンピュ ーターの基礎研究に携わる。い まは、AgentのEvalの仕組み と、Trooper Coreのシステム開 発を担う。 鬼澤 輔 三浦 理久 CORE ENGINEER / INTERN ワダゲリ 多美真 トロント大学 コンピュータサイ エンス専攻。フロントエンドから バックエンド、AI・LLMまで。い まはTrooper Coreの開発で、 画面から実行基盤までを実装 する。 Agentを、企業の現場に届けるメンバー ENGINEERING CONSULTING FORWARD DEPLOYED FORWARD DEPLOYED 東京大学 文学部出身。エネルギー系VC でのインターンを経て参画。企業導入の 基盤とインフラを担う。 東京大学 農学部出身。アクセンチュア戦 略部門を経て参画。ユースケース策定か ら導入まで、顧客の最前線に立つ。 VCの客員起業家、3Dアバター領域での 起業を経て参画。企業に入り込み、Agent 早稲田大学 創造理工学部出身。経営工 学のデータ分析を経て参画。業務データ とナレッジで、Agentを業務に実装する。 斉藤 然 A I AG E N T D E S I G N ・ S A LT 2 榊間 一純 岩倉 一暉 を業務に実装する。 中森 健人 39 / 41
40. 5 SA LT 2 について VISION ADVANCE HUMAN HISTORY 人類史を前進させる。 MISSION AI時代に、社会へのインパクトを最大化する。 Products Forward Deployed Consulting Trooperをはじめ、会社のDataと権限の中で、仕事を最後 まで終えるAgentの製品。 お客さまの現場に入り、業務の定義から一緒に設計して、 Agentを実際の仕事に届ける。 AI戦略から個別開発、社内でAIを使いこなすための内製 業務で動くAgentをつくる 企業に入り込み、業務に落とす AIを、自分たちのものにする 化まで。 株式会社SALT2・2023年10月設立・東京大学 松尾・岩澤研究室にルーツを持つAIプロフェッショナルファーム・Boost Consulting グループ・salt-2.com AIの技術を、社会で価値あるものにする。AIの社会実装で、世界を前進させる。 A I AG E N T D E S I G N ・ S A LT 2 40 / 41
41. 5 参考資料 参考資料 ANTHROPIC ANTHROPIC ANTHROPIC ANTHROPIC ANTHROPIC ・ 2026-09-01 ANTHROPIC ・ 2026-07-13 ANTHROPIC OPENAI OPENAI ・ 2026-09 UK AISI ・ 2026-08 OWASP ・ 2026-09 OWASP MCP ・ 2026-07-28 AGENT SKILLS PAPER ・ 2026-06 PAPER METR Building Effective AI Agents Demystifying evals for AI agents Managed Agents: Define outcomes Incident report: unsanctioned agent behaviour during cyber testing MCP specification 2026-07-28 τ-bench（pass^k） A I AG E N T D E S I G N ・ S A LT 2 Writing effective tools for AI agents Claude Fable 5.1 and Claude Mythos 5.1 A practical guide to building agents 2026 Top 10 for LLM Applications / Agent Control Standard Agent Skills open standard Effective harnesses for long-running agents Agentic Misalignment in Summer 2026 API Changelog（Agents API） Top 10 for Agentic Applications for 2026 OSWorld 2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks Task-Completion Time Horizons 41 / 41