AIエージェントは便利ですが、実運用となると急にムズかしくなります。
理由はシンプルで、AIは賢いけれど、毎回まったく同じ答えを返すわけではないからです。この記事では、DZoneの記事「ARC: The Architecture for Reasoning Control」で紹介されている考え方を、日本語でわかりやすく紹介します。
ざっくり言うとARCは、AIの“ゆらぎ”を前提にして、ガードレールと決定的な処理（deterministic processing）で囲い込む設計です。
個人的には、これはかなり筋がいい考え方だと思います。AIに全部やらせるのではなく、考える部分だけAIに任せて、実行はコードで固める。この発想は、現場で使えるAIシステムを作るうえでかなり重要です。
ARCは Architecture for Reasoning Control の略で、直訳すると「推論を制御するためのアーキテクチャ」です。
この記事の筆者は、AIアプリやAIエージェントを作る中で見えてきた3つの学びをまとめて、ARCと呼んでいます。
要するに、
この3つです。
この発想、すごく地味に見えるかもしれません。でも実際は、AIを「デモで動くもの」から「ちゃんと使えるもの」に引き上げるための、かなり本質的な話です。
記事の最初のポイントは、AIモデルは非決定的だということです。
非決定的、というのは簡単に言えば同じ入力でも毎回同じ結果になるとは限らないという意味です。
これはクリエイティブな用途では長所になります。
でも、ユーザー対応、ワークフロー、データ処理みたいに「毎回それなりに正しく動いてほしい」場面では、かなり厄介です。
筆者は、1回のモデル呼び出しだけならまだ管理しやすいけれど、
AIエージェントのように
みたいな構成になると、非決定性が積み重なっていくと指摘しています。
たとえば10回連続でAIを呼ぶと、単純に言えば「10回ダイスを振る」ようなもの。
1回なら当たりやすくても、回数が増えるほどどこかで外れやすくなる。これはかなり納得感があります。
記事では、ソフトウェア設計の Single Responsibility Principle（SRP） を引き合いに出しています。
SRPは「1つのモジュールは1つの責務だけを持つべき」という考え方です。
AIでも同じで、1つのAIモジュールにやらせることを増やしすぎないのが大事だ、というわけです。
個人的には、ここがARCの出発点としていちばん大事だと思います。
AIエージェントは「何でもできる」ほど強そうに見えますが、実際には「何でもやらせる」と壊れやすい。かなり皮肉です。
2つ目のポイントは、ガードレールを重ねることです。
ガードレールとは、AIの危ない出力や誤動作を防ぐためのチェック機構のことです。
記事では、1回のチェックで多くの問題は見つかるけれど、「多く」では不十分だと言っています。
なぜなら、ユーザーに出すシステムでは、たまに漏れるくらいでは済まないからです。
筆者は、入力時と出力時に同じロジックで2回チェックするやり方も試したそうです。
でも、これは思ったほど効かなかった。理由は、似たような弱点をそのまま2回繰り返すだけだからです。
たとえば入力段階で見逃した違法クエリが、出力段階でも同じ基準で見逃される。
PII（個人情報）をうまく検知できないなら、2回やっても同じ穴を2回通るだけ。
これは「防御を増やしたつもりで、実は同じ盾を2枚持っているだけ」という感じで、かなり示唆的です。
記事では、異なる角度から守る複数の層を組み合わせるべきだとしています。
たとえば次のようなものです。
Dedicated Scanners（NER & Regex）
NERは「固有表現抽出」で、人名・地名・組織名などを見つける技術。
Regexは正規表現で、カード番号や電話番号などのパターンを機械的に検出できます。
つまり、AIに頼らず機械的に拾える危険は、まず機械的に拾うということです。
Intent Routing
入力を「安全」「あいまい」「高リスク」に分類して、危険なものだけ厳しく扱う仕組み。
これも実務ではかなり大事で、全部を同じ扱いにしないのがポイントです。
Structural Enforcement（JSON Schema）
AIの出力を自由文ではなく、決められたJSON形式に縛る方法です。
こうすると「文章として変かどうか」ではなく、「形が合っているか」で機械的に判定できます。
これはかなり好きな発想です。AIを“しゃべる存在”として扱うのではなく、データを返す部品として扱うわけですね。
LLM-as-a-Judge
別の小さなモデルに、主役のAIの答えを評価させる方法です。
いわば「AIに答えさせて、別のAIに採点させる」形です。
Retrieval-grounded responses（RAG）
これは、検索して取ってきた文脈だけを使って答えさせる考え方。
幻覚（hallucination、もっともらしい嘘）を減らすのに役立ちます。
記事の言いたいことは、完璧なガードレールは存在しないということです。
だから、1本の強い柵を立てるより、弱点の違う柵を何層も重ねるほうが現実的です。
この考え方は、タイトルにもある「Swiss Cheese model」に通じます。
チーズには穴があるけれど、何枚も重ねると穴がずれて、全部が一直線にはつながりにくい。
つまり、1つの防御が抜けても、別の防御で止めるという設計です。
率直に言うと、AI安全性の議論は「完璧に守る」話になりがちですが、現実にはそんなものはないです。
だからこそ、こういう**“壊れない前提ではなく、壊れても致命傷にならない前提”**の設計が大切なんだと思います。
3つ目のポイントは、この記事の中でいちばん実践的です。
それは、AIと決定的な処理を分けることです。
記事の主張は明快で、AIには「何をするか」を決めさせ、コードには「どう実行するか」をやらせるべきだ、ということです。
これは本当に重要です。
AIにワークフロー全体を自由に歩かせると、便利そうに見えて、実はかなり危険です。
一方で、AIを「考える部品」に限定すれば、システム全体のふるまいはかなり安定します。
記事ではこの発想を Flow Engineering と呼んでいます。
要するに、LLMを“自由に動く司令塔”にするのではなく、決められた工程の中でだけ頭脳として使うやり方です。
たとえば、
という流れです。
この構成だと、
というメリットがあります。
個人的には、ここがいちばん「現場で効く」ポイントだと思います。
AIの理想像は「全部やってくれる万能秘書」ですが、実際のプロダクトではむしろ、一部だけ賢い部品として組み込んだほうが安定することが多いです。
この記事を読んで印象的だったのは、ARCが単なる「AIを厳しく制限する話」ではないことです。
むしろ逆で、AIを使う場所を絞ることで、AIの強みをちゃんと活かすための設計に見えます。
AIに全部任せると不安定になる。
でも、使う場所を限定すれば、AIはかなり役立つ。
このバランス感覚がARCの本質ではないでしょうか。
この流れは、AIエージェントを「すごいデモ」から「業務で使える仕組み」に変えるうえで、とても筋がいいです。
ARCは、AIエージェントを安定して動かすためのかなり現実的な設計思想です。
ポイントは、AIのランダムさを消そうとするのではなく、ランダムさを前提にして囲い込むこと。
記事のメッセージを一言でまとめるなら、
「AIには賢い判断をさせ、実行は決定的なコードで固める」です。
これは派手さはないけれど、たぶん本当に大事な考え方です。
AI時代のシステム設計は、「どこまでAIに任せるか」を見極める仕事になっていくのではないか、と思います。
