全体アーキテクチャ

• ページ作成日時：2026-07-20 11:22 JST
• 最終更新日時：2026-07-20 11:22 JST

ここまで、生成AIのしくみをいくつかの部品に分けて見てきた。

01では、ユーザー入力がそのままモデルへ流れ込むのではなく、request objectとして組み立てられることを見た。

02では、system / developer / user / tool result などの指示階層を見た。

03では、context、memory、RAG、file input、context windowを扱った。

04では、tool callとapplication execution、そしてtool resultが再びcontextへ戻るloopを扱った。

05では、JSON Schema、Structured Outputs、parse、validate、repair、handoffを扱った。

06では、memoryを、保存・参照・注入・監査の仕組みとして見た。

07では、agentic loopを、停止条件、budget、verification、guardrails、handoff、traceとして扱った。

08では、これらを一枚の全体図に戻す。

中心にある問いは、これである。

生成AIシステムにおいて、model、application、runtime、tool、memory、humanは、それぞれ何を担当し、どこで責任境界が切られているのか。

1. 生成AIシステムはmodelだけではない

日常的には、私たちはこう言う。

AIが答えた
AIが検索した
AIがファイルを読んだ
AIがメールを書いた
AIがNotionにページを作った
AIがコードを直した

もちろん、日常語としてはこれでよい。

しかし、しくみとして見るなら、この言い方はかなり粗い。

モデルが直接Webを検索しているとは限らない。

モデルが直接ファイルシステムを読んでいるとは限らない。

モデルが直接メールを送っているとは限らない。

モデルが直接NotionやGoogle Driveを書き換えているとは限らない。

モデルが直接データベースや外部APIを操作しているとは限らない。

多くの場合、モデルがしているのは、次のような出力を生成することである。

natural language answer
structured output
tool call request
reasoned next-step proposal
refusal
clarification request
handoff proposal

それを受け取ったapplicationが、構造を確認し、権限を確認し、toolを呼び、runtimeが実行し、結果を受け取り、必要なら再びmodelへ戻す。

つまり、外からは「AIがやった」ように見えることの多くは、実際には複数の層の協働である。

"AI did it"
  = model generated something
  + application interpreted it
  + runtime executed something
  + tool returned a result
  + application verified or displayed it
  + human accepted, corrected, or approved it

「AIがやった」を分解しなければ、どこで失敗したのか分からない。

モデルが誤ったのか。

contextが足りなかったのか。

instruction placementが悪かったのか。

tool schemaが曖昧だったのか。

runtime executionが失敗したのか。

validationが弱かったのか。

human approvalが必要だったのか。

そもそも委任してはいけない判断だったのか。

全体アーキテクチャとは、この責任境界を見えるようにすることである。

2. 四つの大きな層

生成AIシステムは、まず大きく四つの層に分けられる。

この四層は、単純な上下関係ではない。

責務の違いである。

modelは、入力されたcontextから次の出力を生成する。

applicationは、何をcontextへ入れ、何をtoolとして許し、出力をどう扱うかを決める。

runtimeは、外部世界への接続を実行する。

humanは、目的、意味、責任、承認、評価を持つ。

AI system ≠ model alone

AI system =
  model
  + application orchestration
  + context assembly
  + tool runtime
  + memory / retrieval
  + validation / verification
  + guardrails
  + human judgment
  + audit trail

この分担が曖昧になると、生成AIシステムは一気に危険になる。

モデルの限界をapplicationの設計で補うべきところを、モデルの賢さに丸投げしてしまう。

runtimeの副作用をhuman approvalで制御すべきところを、「AIが判断したから」で通してしまう。

検証すべきtool resultを、自然文の完了報告で置き換えてしまう。

全体設計の第一原則は、modelを神格化しないことではなく、modelを正しい場所に置くことである。

3. requestからresponseまでのpipeline

生成AIシステムをpipelineとして見ると、次のようになる。

1. user intent
2. request assembly
3. instruction hierarchy placement
4. context selection
5. memory / retrieval injection
6. tool schema exposure
7. model invocation
8. output parsing
9. validation / refusal handling
10. tool execution or direct response
11. result observation
12. verification
13. loop decision
14. final response / artifact / handoff / stop
15. trace / audit / evaluation

これは単なる実装手順ではない。

責任境界の一覧である。

どの段階で何を確認するのか。

どの段階で人間へ返すのか。

どの段階でtoolを許可するのか。

どの段階で止めるのか。

どの段階を記録するのか。

それぞれを分けなければ、生成AIシステムは「なんとなく賢い黒箱」になる。

4. model layerの責務と限界

model layerの責務は、与えられたcontextから次の出力を生成することである。

ここでいう出力は、自然文だけではない。

answer text
structured output
tool call candidate
classification
plan
refusal
clarification request
handoff proposal

modelは、入力されたcontextの中からパターンを見つけ、推論し、生成する。

文章を作る。

構造化されたJSONを作る。

toolを呼ぶべきだと判断し、tool call候補を出す。

質問が危険または不可能であれば拒否する。

情報が足りなければ確認を求める。

しかし、modelには限界がある。

model output ≠ external fact
model output ≠ tool execution
model output ≠ permission
model output ≠ user approval
model output ≠ completed task

modelが「ファイルを作成しました」と言っても、本当にファイルが存在するとは限らない。

modelが「メールを送信しました」と言っても、実際に送信されたとは限らない。

modelが「この情報は正しいです」と言っても、それだけではsource of truthではない。

modelが「このtoolを使います」と言っても、使ってよいとは限らない。

model says X happened ≠ X happened

modelは、source of truthではない。

modelは、memory storeでもない。

modelは、外部世界を直接操作する主体でもない。

modelは、責任主体でもない。

だから、model outputとapplication actionを分ける必要がある。

5. application layerの責務

application layerは、modelを呼び出すだけの薄い殻ではない。

むしろ、生成AIシステムの中核的な編成層である。

application layerは、少なくとも次を担う。

application layerで重要なのは、「何をmodelに渡すか」と「modelから返ったものをどう扱うか」である。

application decides:
  what the model sees
  what the model may call
  what counts as valid output
  what requires approval
  what should be retried
  what must stop
  what should be shown to the user

同じmodelでも、application設計が違えば、まったく違うシステムになる。

安全なapplicationは、model outputをそのまま外部世界へ流さない。

一度受け取り、構造を確認し、権限を確認し、必要なら検証し、人間へ戻し、traceを残す。

6. runtime / tool layerの責務

runtime / tool layerは、生成AIシステムにおける外部世界への実行境界である。

toolは、単なる「能力追加」ではない。

境界である。

tool = capability + permission boundary + side effect boundary + audit boundary

runtime / tool layerには、次のようなものが含まれる。

• hosted tools
• local runtime tools
• connectors
• external APIs
• file system
• database
• browser / computer control
• sandbox
• code interpreter
• workflow engine
• job queue

modelがtool call候補を出す。

applicationがschemaと権限を確認する。

runtimeが実際に実行する。

tool resultが返る。

applicationがそれを観測し、検証し、必要なら再びmodelへ渡す。

model emits tool call candidate
  ↓
application validates and authorizes
  ↓
runtime executes
  ↓
tool result returns
  ↓
application verifies
  ↓
model receives result as context

ここで重要なのは、execution resultはtruthそのものではないということだ。

APIが200を返したからといって、taskが成功したとは限らない。

ファイル作成toolが成功したからといって、中身が正しいとは限らない。

検索toolが結果を返したからといって、十分な調査ができたとは限らない。

DB更新が成功したからといって、正しいレコードを更新したとは限らない。

execution succeeded ≠ task succeeded
result returned ≠ result verified
side effect occurred ≠ user intended it

runtime / tool layerでは、permission、credential、side effect、sandbox、auditが重要になる。

特に、外部状態を変える操作では、read-only actionとstate-changing actionを分けなければならない。

read-only action
  ≠ state-changing action

state-changing action
  requires stronger gate

メール送信、公開、削除、上書き、支払い、契約、PR merge、DB更新などは、強いgateが必要になる。

toolは便利さの入口であると同時に、事故の入口でもある。

7. memory / retrieval layerの位置

memoryやretrievalは、modelそのものではない。

多くの場合、保存された情報や外部知識を候補として取り出し、applicationが選別し、contextへ注入する層である。

stored memory
  ↓
retrieval candidate
  ↓
application selection
  ↓
context injection
  ↓
model invocation

memoryが存在することと、今回の応答に使われることは違う。

検索結果が存在することと、信頼できる根拠になることも違う。

ファイルが添付されていることと、context windowに十分入ることも違う。

memory / retrieval layerでは、次を記録する必要がある。

what was retrieved
why it was retrieved
what was injected
what was omitted
what authority it has
whether the user can inspect or correct it

memoryは便利である。

しかし、memoryの注入が見えないと、ユーザーは「なぜその前提で答えたのか」を検証できない。

だからmemoryは、単なるpersonalizationではなく、監査可能なcontext sourceとして扱う必要がある。

8. human layerの責務

human layerは、AIシステムの外側にある飾りではない。

システム構成要素である。

人間は、次を担う。

human-in-the-loopは、単に確認ボタンを置くことではない。

人間が判断できるだけのcontextを返す必要がある。

bad approval:
  "実行してよいですか？"

good approval:
  action: 何をするか
  target: どこに対して行うか
  consequence: 何が変わるか
  reversibility: 元に戻せるか
  evidence: 何を根拠にしているか
  alternatives: 他の選択肢はあるか

人間をloopに入れるなら、人間が判断できる形で情報を渡さなければならない。

9. manifestとして設計する

生成AIシステムを安全に設計するには、暗黙の状態を減らし、manifestとして見える形にする必要がある。

少なくとも、次のmanifestが有用である。

manifestは、開発者向けの内部資料だけではない。

AIシステムを後から説明し、検証し、改善するための足場である。

no manifest → invisible state
invisible state → unverifiable behavior
unverifiable behavior → untrustworthy system

10. failure boundary

生成AIシステムでは、失敗を一種類にまとめてはいけない。

model failure
context failure
instruction failure
schema failure
validation failure
runtime failure
permission failure
verification failure
approval failure
evaluation failure

これらは、すべて違う。

modelが誤ったのか。

contextに必要情報がなかったのか。

外部文書中の命令をinstructionとして扱ってしまったのか。

JSON schemaが曖昧だったのか。

parseやvalidationが弱かったのか。

tool実行が失敗したのか。

権限がなかったのか。

実行結果を確認しなかったのか。

人間の承認が必要だったのに省略したのか。

成果物の評価基準がなかったのか。

failure boundaryを切ることは、責任逃れではない。

改善可能性を作ることである。

wrong answer
  → maybe model / context / instruction / retrieval failure

bad action
  → maybe application / runtime / permission / approval failure

unverified completion
  → maybe validation / verification / audit failure

「AIが間違えた」だけでは改善できない。

どの層で何が起きたかを分ける必要がある。

11. 01〜07の統合

ここまでの各回を、08の全体図に対応させると次のようになる。

このシリーズで一貫していたのは、「生成AIはモデル単体ではなく、入力・指示・context・tool・memory・runtime・humanを含むシステムである」という見方である。

12. 設計原則

最後に、生成AIシステムの設計原則として整理する。

1. modelを単独の主体として扱わない。
2. user inputをそのままmodel inputとみなさない。
3. instruction hierarchyを明示する。
4. contextは保存情報ではなく、今回注入された入力集合として扱う。
5. tool callは実行候補であり、application側で検証する。
6. structured outputは、schema、parse、validate、repairまで含めて設計する。
7. memoryは便利なpersonalizationではなく、監査可能なcontext sourceとして扱う。
8. agentic loopは、続ける能力ではなく、止まる能力として設計する。
9. human approvalは形式的なボタンではなく、判断可能なcontextとセットで置く。
10. traceとauditを残し、後から説明・再現・評価できるようにする。

この10項目は、技術的な細部というより、AIシステムを「信頼できる協働相手」にするための条件である。

13. OpenAI Agents SDKとの対応

OpenAI Agents SDKでは、Agentはinstructionsやtoolsを備えたLLMとして説明され、handoffs、guardrails、structured outputsなどもAgentに関連するprimitiveとして扱われる。また、Agent + Runnerにより、turns、tool execution、guardrails、handoffs、sessionsなどをSDK側で管理できる。さらにtracingは、LLM生成、tool call、handoff、guardrailなど、agent run中のeventsを記録する仕組みとして説明されている。

このシリーズの整理に引き寄せるなら、対応は次のように読める。

Agent / model
  → model layer

Runner / orchestration
  → application loop layer

tools / connectors
  → runtime / tool layer

guardrails / handoffs / tracing
  → control and audit layer

sessions / context management
  → memory / context layer

human approval / review
  → human layer

ただし、これは特定SDKの説明をそのまま一般理論にするという意味ではない。

重要なのは、どのframeworkを使うかではなく、責任境界を消さないことである。

14. 結論

生成AIシステムとは、modelだけで成立するものではない。

modelは、入力されたcontextから次の出力を生成する。

applicationは、request、instruction、context、memory、tool、validation、loopを組み立てる。

runtimeは、実際のtool、API、file system、database、network、sandboxを扱う。

memory / retrieval layerは、保存情報や外部知識を候補として取り出し、contextへ注入する。

guardrailsは、許可・禁止・確認・停止を判定する。

humanは、目的、判断、承認、責任、評価を担う。

audit trailは、それらの振る舞いを後から説明可能にする。

model
  + application
  + runtime
  + memory
  + tools
  + guardrails
  + human
  + audit
  = AI system

「AIがやった」と見える出来事は、実際には複数層の協働である。

だから、生成AIを理解するとは、モデルの中身だけを理解することではない。

モデルの周囲にある、request、instruction、context、tool、memory、runtime、human、auditの配置を理解することでもある。

そして、AIを安全に使うとは、AIを信じることではない。

どの層が何をしているかを見えるようにし、どこで確認し、どこで止め、どこで人間が判断するかを設計することである。

この全体像を持つと、生成AIは単なるチャット画面ではなくなる。

それは、modelとapplicationとruntimeとhumanが協働する、新しい実行環境として見えてくる。

参考

• OpenAI Agents SDK
• OpenAI Agents SDK｜Agents
• OpenAI Agents SDK｜Running agents
• OpenAI Agents SDK｜Tracing