無限にスケールするAI組織の作り方：評価・役割分担・記憶で作る自律改善エージェント
以前公開したブログ「ハーネス・エンジニアリングが、次の10年の堀になる理由」では、AIの能力を仕事の成果に変える「ハーネス」が、これからの競争優位になる理由を論じた。
本記事では、その続編である。
多くのAI活用は、良いプロンプトを書く。便利なツールをつなぐ。単発の自動化を作るところで止まる。
しかし、成果を判定する役割、失敗を記録する場所、次に活かす記憶がなければ、毎回人間が同じように確認し、同じように直し、同じように迷うことになる。
本記事で扱うのは、その先である。
ハーネスを個人の工夫で終わらせず、評価・役割分担・記憶を備えた「AI組織」として設計する方法を整理する。
キーワードは、評価・役割分担・記憶だ。
planner / generator / evaluator に責任を分け、Outcomeに照らして成果を評価し、Run LogとMemoryで失敗と成功を次に活かす。人間が毎回つきっきりで直すAI活用から、合格するまで自律的に改善し続けるAI組織へ移行するための設計図をまとめる。
想定読者
生成AIを毎日使っているが、成果が個人の工夫やプロンプト力に依存していると感じている人
AIエージェント、サブエージェント、ワークフロー自動化を試したものの、品質評価や失敗時の扱いに悩んでいる人
AI活用をPoCや便利ツールで終わらせず、継続改善する業務システムとして運用したい人
経営、開発、リサーチ、営業、コンテンツ制作などの反復業務を、AIに任せられる形へ再設計したい人
この記事で学べること
単発プロンプトから、Outcomeに基づいて改善し続けるAI組織へ移行する考え方
planner / generator / evaluator の責任を分け、評価可能な業務ループを作る方法
Run LogとMemoryを使って、AIの実行履歴を次の判断に効く経験へ変える方法
評価関数の業務タイプ別設計、暗黙知の形式知化、Multi-agent化によってAI組織を強くする方法
全体ストーリー
AIへのアクセス自体は、もはや差別化ではなくなった
差がつくのは、モデル性能ではなく、成果を出し続ける運用構造である
その最小単位は、Outcome、役割分担、評価関数、Run Log、Memoryで構成される
まず1つの業務で、生成、評価、改善、記憶のループを閉じる
その後、評価設計、暗黙知の形式知化、責任境界の分割によって、別業務へ展開できる形に強くする
最終的に、評価と改善の型を複製できる状態が「スケールするAI組織」である
基礎編：AI組織を成立させる
1. はじめに：AIを「使う」から、AIが成果を出し続ける仕組みを作るへ
生成AIの普及によって、フロンティアモデルへのアクセスは「持っているか／いないか」の問題ではなくなった。
ChatGPT、Claude、Geminiといった最先端モデルは、月数十ドルのサブスクリプションかAPIキー一つで誰でも触れる。
社内SlackからAIに話しかけ、エディタの横でAIにコードを書かせる――そんな光景は、もはやどの組織でも珍しくない。
それにもかかわらず、AI活用の成果には組織ごとに大きな差が生まれている。同じモデルを使っているはずなのに、片方では生産性が3倍になり、もう片方では「便利な検索ツール」止まりで終わる。この差は何から生まれているのか。
結論から言えば、差が出ているのはモデル性能ではなく、AIをどう動かし続けるかという運用構造である。
誰がゴールを定義し、誰が成果物を生成し、誰が品質を評価し、その結果をどこに蓄え、次にどう活かすのか。
この一連の流れが設計されているかどうかが、成果の差を決めている。単発のプロンプトが上手いかどうかは、もはや本質ではない。
本記事の問いはここにある。どうすればAIを「単発の作業者」ではなく、「成果を出し続ける組織」として動かせるのか。個人が思いつきで使うAIから、業務として継続的に改善されていくAIへと、いかにして移行するか。
先に結論を提示しておく。
継続的に成果を出すAI組織とは、Outcome（達成したい成果）に照らして、生成・評価・改善・記憶を回し続ける仕組みである。
本記事ではこれを「ハーネス（harness）」と呼ぶ。馬具のharnessが力を引き出す方向を制御するように、AIの能力を成果の方向へ束ねる構造のことだ。
ハーネスは、planner（計画する役）、generator（生成する役）、evaluator（評価する役）という役割分担、Outcomeに紐づいた評価関数、実行履歴を残すRun Log、そして次のループに引き継ぐMemoryから構成される――これらの個々の要素については後の章で詳述する。重要なのは、AI組織の差はモデルではなく「この構造を持っているか」で決まり始めているという事実だ。
次章では、まずこの「ハーネス」という概念をもう一段掘り下げ、なぜそれが今、競争力の中心になりつつあるのかを論じる。
2. 「無限にスケールするAI組織」とは何か：モデルではなくハーネスで戦う
前章で立てた問い──AIを単発の作業者ではなく「組織」として動かすには何が必要か──に答える前に、まず誤解を解いておく必要がある。
「無限にスケールするAI組織」とは、AIエージェントを大量に並べた状態のことではない。
エージェント数を増やしても、目標がぶれ、評価が場当たり的で、過去の失敗が記録されないままなら、それは単に高コストな混乱を量産するだけである。スケールしているのは作業量であって、組織ではない。
ここでスケールの定義を改めて固定したい。本稿でいうスケールとは、「エージェント数の増加」ではなく「判断と改善の型を複製できる状態」を指す。
目標を定義し、役割を分け、評価し、改善し、記憶する──このループが一つの単位として閉じており、別の業務・別のチーム・別のドメインに移植できる。これが、スケールする組織の最小条件である。
この移植可能なループを、本稿では一貫して「ハーネス」と呼ぶ。ハーネスとは、AIモデルを実用化するための手順・評価・安全策・記録を一体として束ねた運用構造である。
プロンプトテンプレートの寄せ集めでも、ツールの組み合わせでもない。判断と改善が同じ場所で行われ、その痕跡が次の実行に効いてくる、統合された運用の骨格を指す。
ここでメタファーを一つだけ用意する。モデルはエンジンであり、ハーネスは車体である。
エンジン単体ではどれだけ高性能でも、人や荷物は運べない。シャシー、サスペンション、ブレーキ、計器盤、シートベルト──これらを統合してはじめて「乗り物」になる。
AI活用も同じである。最先端モデルへのアクセスは前提条件にすぎず、それを業務成果へ変換するのは、その周囲を取り囲む構造である。
この前提に立つと、競争優位の所在が見えてくる。
成果物そのものではなく、成果物を再現し続けるハーネスに優位は宿る
一発のヒットではなく、外したときに学習して次に効かせる仕組みに価値がある
担当者の勘ではなく、勘を構造化して誰でも回せる形にした手順が資産になる
この転換は、運用思想そのものの転換でもある。
これまでAI活用の現場では、人間がプロンプトを工夫し、出力を逐次確認し、細かく軌道修正し続ける「指示の運用」が主流だった。
これは属人化を生み、担当者のスキルがそのまま生産性の上限になる。
ハーネスを中心に据えた運用は、これを「成功条件の設計」へと反転させる。
何をもって成果とみなすか、どの条件を満たせば次工程へ進めてよいか、失敗時に何を記録し何を改善するか──人間はこの上位レイヤーを設計し、個別判断はループの中に委ねる。
つまり、スケールする単位は「人の代替」ではない。スケールする単位は、判断と改善の型である。
次章では、この型を最小構成で組み上げるための三つの役割──planner / generator / evaluator──に踏み込む。
3. 基本の3役：planner・generator・evaluator
前章では、AIに継続的に仕事をさせるための土台として「ハーネス」という枠組みを紹介した。
本章では、そのハーネスの中で実際に動くことになる3つの基本役を押さえる。
詳しい設計論は後続章に譲り、ここではまず「誰が何をやるのか」だけを掴んでもらえればよい。
AI組織の最小単位は、以下の3役に集約できる。
プランナー（planner）＝計画役：目的と直近の評価結果を読み、仕事を分解し、次に何をどう改善するかの方針を決める。
たとえば「営業提案書のドラフト作成」というゴールに対して、「顧客課題の整理→競合比較→提案骨子→具体化」と工程を切り、前回の評価で不足していた点を踏まえて優先度を組み直す。ジェネレーター（generator）＝生成役：プランナーが決めた指示と制約に沿って、実際の成果物を作る。
文章、スライド、コード、設計、分析レポートなど、現場でアウトプットそのものを担うのがこの役である。「とにかく書く・作る」のがgeneratorの仕事で、品質判断は本人の仕事ではない。エヴァリュエーター（evaluator）＝評価役：generatorが出した成果物を、事前に定めた成功条件と照らして採点し、合否を判定する。
「顧客課題が固有名詞で書かれているか」「数字に根拠があるか」「結論が一文で言えるか」などをチェックリスト的に潰し、不合格ならどこが足りないかを言語化して返す。
ここで一番重要なのは、計画するAI・作るAI・評価するAIを「役割」として分けるという点である。
同じAIに3役を兼ねさせると、必ずと言っていいほどgeneratorが自己評価で甘くなる。「自分で書いたものを自分で点検する」状況では、AIは無意識に成果物を擁護する側に回り、粗を見逃す。結果、評価結果が常に「だいたい良い」となり、改善ループそのものが動かなくなる。
したがって鉄則はこうだ。generator自身に自己採点をさせず、別コンテキストのevaluatorを必ず置く。同じモデルを使うとしても、プロンプトとコンテキストを切り離し、「生成した本人ではない誰か」が評価する構造にする。これだけで、出力品質のブレ幅と改善速度がはっきり変わる。
なお、本章で挙げた3役は、後続章で扱う以下の4つの道具立てと組み合わせて初めて意味を持つ。
それぞれの詳細は次章以降で深掘りするので、ここでは名前と役割だけ覚えておけばよい。
ざっくり言えば、Outcomeで「ゴール」を決め、rubricで「合否の物差し」を作り、Run Logで「今回の動き」を残し、Memoryで「次回に活かす知見」を貯める。3役はこの4つを共通言語として動く。
最後に一点、注意を入れておく。
ここでの「3役」はあくまで責任分離の最小単位であって、必ずしも物理的に3つのエージェントを立てなければならないという話ではない。
同じモデルを使い回しつつ、プロンプトとコンテキストを切り替えるだけでも3役は成立する。
役割を物理的に分割し、複数エージェントを並列に走らせるMulti-agent構成は、組織を本格的にスケールさせる段階で必要になる話で、本書では応用編で扱う。
まずは「責任を分ける」ことと「エージェントを分ける」ことは別物だと押さえておけば十分である。
4. Outcome設計：AI組織の目的関数を作る
第3章では、planner / generator / evaluator の3役が同じ方向を向くために「Outcome」という共通基準が必要だと予告した。
本章ではその中身を定義する。
従来のITは、業務手順（How）を仕様化することで自動化を実現してきた。
「このボタンを押したらこのAPIを叩く」「この条件分岐ではこの処理を呼ぶ」と、ロジックを細部まで書き下す世界である。
一方、AI組織が自動化するのは手順ではない。成果（What）を評価可能にすることで、生成過程をAIに委ねるのがコアの発想だ。
「どう書くか」ではなく「何を満たせば成功か」を明文化する。このパラダイムシフトを最初に飲み込んでおきたい。
Outcomeとは何か
Outcomeは「この仕事は何を満たせば成功か」を明文化したものである。
数式やスコアそのものではなく、業務上の成功条件・制約・失敗条件を含む、評価可能な仕様として扱う。
evaluatorはこれを読み、planner / generatorもこれを読む。組織の目的関数そのものだ。
Outcomeに書くべき要素は以下の5つである。X（旧Twitter）投稿生成タスクを例に並べると輪郭が掴みやすい。
Must Pass Criteria（必達条件）：これを満たさなければ即不合格となる絶対条件。
例：「140字以内であること」「事実誤認を含まないこと」。一つでも欠ければOutcome未達と判定される。Quality Criteria（品質基準）：高品質と見なされるための条件。
例：「冒頭1行でフックがある」「具体的な数字または固有名詞が含まれる」。満たすほど点数が上がる加点要素。Constraints（制約）：守るべき制限事項。
例：「絵文字は3個まで」「特定の競合製品名は使用禁止」「ハッシュタグは2個以内」。守れないと体裁が崩れる枠組み。Failure Conditions（失敗条件）：該当したら明確に不合格と判定する条件。
例：「センシティブワードを含む」「未公開情報に言及している」。Must Passの裏返しではなく、踏んだ瞬間に即停止する地雷リストとして書く。Scoring Rubric（採点表）：evaluatorが点数化に使う基準。
例：「フック強度0〜3点、具体性0〜3点、行動喚起0〜2点、合計8点中6点以上で合格」。Quality Criteriaを点数に翻訳する変換表である。
この5要素が揃って初めて、Outcomeは「人間の頭の中の合格ライン」から「AIが繰り返し参照できる仕様」へと昇格する。
自動化対象として成立するかを見極める3軸
すべての業務がAI組織化に向くわけではない。手を出す前に、対象業務が次の3軸を満たすかをチェックリストとして確認する。
Rewardable（評価できる）：成果物の良し悪しを判定できるか。
Outcomeが書けるか、と言い換えてもよい。「センスが良い感じ」しか言語化できない仕事はここで詰まる。Resettable（やり直せる）：失敗しても安全に再実行できるか。
本番DBを更新する、顧客にメールを送るといった不可逆な副作用を伴う仕事は、ループを回す前提が崩れる。
ステージングや下書きで止められる構造になっているかを問う。Efficient（評価コストが回る）：評価コストが生成コストに対して見合うか。
1回の生成に10円かかるのに、evaluatorに1000円払うようでは経済が回らない。
評価を自動化できる、もしくは評価を一度作れば再利用できる仕事に絞る。
この3軸のうち一つでも欠ければ、その業務はAI組織化には早い。先にOutcomeを書ける構造、ロールバック可能な経路、評価の安価化、のいずれかから整備する必要がある。
結論：評価できなければ改善できない
AI活用のコアは、手順を細かく書くことではなく、成果を評価可能にすることだ。
Outcomeを書く能力こそが、AI組織を運用する側の中核スキルになる。
次の第5章では、このOutcomeをevaluatorがどう採点に翻訳するか――Scoring Rubricを実運用の評価関数に落とし込む手順を扱う。
ここで一つだけ強く言い切っておきたい。評価できない仕事は、AI組織化できない。
改善ループはOutcomeという錨があって初めて回る。錨のない船は、どれだけ速く漕いでも、目的地には着かない。
5. 評価関数の基礎：evaluatorは何を見て合否判定するのか
第4章ではOutcomeの5要素を定義した。
本章では、その中でも特に運用上の中核となる Scoring Rubric（採点基準）と Failure Conditions（失敗条件）を、evaluator（評価役）が実際にどう運用するか に焦点を当てる。
評価関数は、AI組織における「合否判定の脳」である。
ここが緩いと、generatorが何を出してきても通ってしまい、ループが空回りする。ここが厳しすぎると、永遠に合格しない。
基礎編で押さえるべきは、設計の細部ではなく、「誰が」「何を見て」「どう返すか」 の三点である。
5.1 rubric・失敗条件・合格ラインの三点セット
evaluatorの仕事は曖昧な「良し悪し」を吐くことではない。次の三点を明示的に持たせる必要がある。
Scoring Rubric：何を、どの観点で、どの程度の基準で評価するか（例：仕様充足度、テストカバレッジ、可読性などを各5点満点で採点）
Failure Conditions：これに該当したら無条件で不合格、というハードな足切り条件（例：テストが落ちている、セキュリティ要件違反、出力フォーマット崩壊）
Pass Threshold：合格と判定するラインの数値化（例：「全項目4点以上かつ失敗条件ゼロ」）
この三点が揃って初めて、evaluatorの判定は再現性を持つ。「なんとなく良さそう」を排除することが、自律改善ループの前提となる。
5.2 出力形式の固定：これが運用の生命線
基礎編で 最も重要なポイント はここである。evaluatorの出力は、必ず固定フォーマット（JSON等）で返させる。具体的には少なくとも次の三要素を含む。
verdict：pass / fail（または条件付きpass）
scores と reasons：各rubric項目のスコアと、その判定理由
improvement_instructions：次のgenerator実行に渡す、具体的な改善指示
なぜ形式固定が重要か。評価結果は次のループの入力になる からである。
自由形式の感想文では、次のgeneratorが何を直せばよいか機械的に取り出せない。JSONで構造化されていれば、改善指示だけを抽出してプロンプトに自動注入できる。ループが回るかどうかは、ここで決まる。
5.3 自己評価の罠：generatorに評価させない
第3章で触れた通り、generator自身に自己評価させてはいけない。
生成中の作業文脈に引きずられ、「ここまで頑張ったから多分OK」という思い込みが入る。自分の出力の弱点は、自分では見えない。
evaluatorは 別コンテキスト で走らせる。
生成過程の苦労を知らない、rubricと成果物だけを見る役を立てることで、見落としと自己正当化の両方が減る。同じモデルでも、コンテキストを分けるだけで判定の独立性は大きく上がる。
5.4 業務タイプによって設計は変わる
ここまでは評価関数の 共通骨格 を扱った。一方で、評価関数の中身は業務タイプによって大きく異なる。
コーディングのようにテスト実行で機械的に判定できる業務もあれば、コンテンツ制作のように代理指標（読みやすさ、構成、事実整合性など）を組み合わせる必要がある業務もある。
業務タイプ別の評価設計の詳細は、応用編第10章 で扱う。基礎編としてここで押さえるべきは、「rubric・失敗条件・合格ライン」「出力形式の固定」「別コンテキストでの評価」の三点である。
次章では、この評価関数を組み込んだループ構造そのものを見ていく。
6. ループ構造：一発勝負ではなく、合格まで回す
前章で「評価関数」を設計した。だがその評価は、ただ良し悪しを記録するためにあるのではない。
評価は、次の生成を駆動するための入力である。ここで必要になるのが、生成と評価をつなぐループ構造だ。
LLMにタスクを一回投げて「完成」とするのは、人間でいえば下書きをそのまま提出するのに等しい。
zero-shotで合格水準に達することは稀であり、達したとしてもそれは運に近い。
AI組織が安定して成果を出すためには、一発勝負ではなく、合格まで回す仕組みが要る。
基本ループ：生成 → 評価 → 改善指示 → 再生成
ループの構成要素はシンプルである。
generator が初稿を作る
evaluator が第5章で定義した評価関数に照らして採点する
合格なら終了。不合格なら planner が評価結果を具体的な改善指示に変換する
generator が改善指示を受けて修正版を生成する
再度 evaluator が評価する。合格するまで2〜4を繰り返す
ここで重要なのは、evaluator の出力（スコア・指摘）をそのまま generator に戻さない点である。
評価は「何が悪いか」を述べるが、改善指示は「次に何をすべきか」を述べる。
両者は別物であり、間に planner を挟むことで、generator は迷わず修正に集中できる。
終了条件を必ず定義する
ループは放っておけば無限に回りうる。実装上、以下を必ず先に決めておくこと。
最大試行回数（例：3〜5回）
失敗理由の記録形式（どの軸で何点足りなかったか）
未達時の扱い：人間にエスカレーション／部分成果として出力／タスク自体を取り下げ
未達時の扱いを決めずにループだけ実装すると、コストが青天井になり、運用者が止め時を判断できなくなる。
メタ改善：Outcome 自体を見直す
何度ループしても合格しない場合、疑うべきは generator の能力ではなく、Outcome 設定そのものであることが多い。
評価基準が現実離れしていないか
入力情報が不足していないか
そもそも一つのタスクに詰め込みすぎていないか
このため、ループには「N回連続で同じ軸が落ちたら Outcome を再検討する」というメタ条件も組み込んでおく。
改善対象は生成物だけでなく、ルブリック・入力・タスク分割の粒度にまで及ぶ。これがAI組織を「自律改善システム」たらしめる本丸である。
次章では、こうしたループの結果を忘れずに次回に活かすための Memory 設計を扱う。
7. Memory管理：ログを「経験」に変える
第6章で改善ループの回し方を見た。1回回せばタスクは終わるが、それだけでは組織は賢くならない。
回した結果を「次の判断に効く形」で残して初めて、AI組織は経験を積んだと言える。本章では、その記録の二層構造を整理する。
Run LogとMemoryは別物である
混同されやすいが、両者は性質が異なる。
Run Log：今回の実行記録。入力、出力、評価スコア、改善指示、失敗理由、所要時間などが含まれる。1タスクごとに増える。役割は「監査」と「振り返り」。
Memory：次回以降も使う判断ルール。ユーザーの好み、禁止事項、繰り返し効いた成功パターン、過去に踏んだ地雷の回避策。役割は「判断の前提を共有する」こと。
Run Logは「今回どう動いたか」の記録、Memoryは「次回どう動くべきか」の指針。前者は過去形、後者は現在形で書かれる、と整理するとよい。
Memoryに入れるべきもの／入れてはいけないもの
判断基準は単純で、「次のタスクでも効くか」だ。
入れるべきもの
評価で繰り返し減点される観点（例：「結論を先頭に置く」「数値には単位を必ず付ける」）
ユーザーの確定した好み（トーン、フォーマット、避けたい表現）
禁止事項・コンプライアンス制約（個人情報、社外秘の扱い）
再現性のある成功パターン（このタイプの依頼にはこの構成が効く）
入れてはいけないもの
一回限りの事実（「今回のIssue番号は#1234」）
まだ検証されていない一発の成功例
個別ユーザーの一時的な要望
Run Logにあれば十分な実行詳細
入れてはいけないものをMemoryに混ぜると、ノイズが蓄積して判断が鈍くなる。Memoryは「組織が信じている共通前提」であり、流量制限が必要な棚である。
経験を組織のものにする
属人化した組織では、判断のコツはベテランの頭の中にある。AI組織でこれを再現すると、特定エージェントのプロンプトや会話履歴に経験が閉じ込められ、別エージェントから参照できなくなる。Memoryはこれを防ぐ共有棚である。誰が起こしたタスクであろうと、同じMemoryを参照して同じ前提で判断する。経験が個ではなく組織に帰属する状態を作るのが、この層の本質的な役割だ。
整理運用（Dreaming）の予告
Memoryは放置すると、重複、矛盾、古いルール、廃止された前提が混ざり始める。
これらを定期的に振り返り、統合・破棄・更新する運用が必要になる。我々はこれを「Dreaming」と呼ぶ。ログとMemoryを寝かせて整理する工程である。
詳細は応用編第11章で扱う。本章ではまず、「Run LogとMemoryを分けて貯める」「Memoryには次回も効く判断だけを入れる」という最小ルールを押さえれば十分だ。
経験を組織の資産に変える土台はこれで揃った。次章では、その土台の上で人間が果たすべき役割を整理する。
8. 人間の役割はどう変わるか：基礎編の締めとして
ここまでで、AI組織を動かす基本要素を一通り提示した。三つの役割、Outcome、評価、ループ、Memoryである。
これらを組み上げると、確かに「AIだけで回る」ように見える領域が広がる。すると必ず出てくる問いがある。
「では人間は要らなくなるのか」というものだ。本章では、この煽りに対して冷静に答えておきたい。結論から言えば、人間は要らなくならない。
ただし、役割は確実に移る。
これまでの人間の仕事の多くは「作業者」だった。コードを書く、ドラフトを書く、伝票を捌く、レビュー指摘を一件ずつ直す。
AI組織が機能し始めると、こうした個別作業の大半はAIワーカー側に吸収される。
代わりに人間に残るのは、設計者・評価者・責任者としての仕事である。設計者として、何を作るかと「何を成功とするか」を言語化する。
評価者として、AIの出力を見て、それが本当に成功条件を満たしているかを判断する。責任者として、最終的な意思決定とアウトプットに対して説明責任を負う。
中でも最も本質的なのが「Outcomeを書く」という作業だ。第3章でも触れた通り、AI組織の挙動は評価関数に支配される。
評価関数を決めるのは、結局のところ人間である。
何をもって「良い成果」とするかが曖昧なまま走らせれば、AIは見栄えの良いが的外れな成果物を量産する。
Outcomeとrubricを書くことは、もはやドキュメント作成ではなく、組織の方針決定そのものだと捉えたほうがよい。
もうひとつ、人間が担うべきは「どこまでAIに任せ、どこで人間が介入するか」の線引きである。
低リスクで反復的な作業は思い切ってAIに委ねてよい。
一方、顧客との契約条件、課金ロジック、認証認可、医療や法務の判断のような高リスク領域では、Human Reviewを明示的に組み込む必要がある。
ここを曖昧にしたまま「全部AIで」と走ると、いつか取り返しのつかない事故が起きる。
AIに任せる範囲と、人間が責任を持つ範囲を意図的に分けることこそ、AI組織設計の核心である（具体的な境界の引き方は第16章で扱う）。
最後に強調しておきたいのは、人間のレビュー観の転換である。これまでのレビューは、目の前の成果物を「全件直す」ためのものだった。
AI組織では、これを 「Outcome・rubric・Memoryを更新するためのレビュー」 へと移していく。
個別の指摘で一件ずつ直すのではなく、「なぜそのミスが起きたのか」をルールやMemoryに昇華し、次回以降AI側が同じ過ちを繰り返さないようにする。
レビューの目的は、目の前の一件を直すことから、組織全体の判断基準を進化させることへとシフトするのだ。
人間の仕事は減るのではなく、抽象度が上がる。これが基礎編の締めくくりとして、最も伝えておきたい論点である。
9. 基礎編まとめ：まず1つの業務をAI組織として回す
ここまでで、AI組織の最小構成要素はそろった。最後に、いきなり全社展開せず「まず1つの業務」から回すための行動指針として基礎編を締めくくる。
業務選定チェックリスト：Rewardable / Resettable / Efficient
最初の対象業務は、次の3軸で選ぶ。
Rewardable（評価できる）：成果物の良し悪しを、人間または評価関数で判定できるか。判定が曖昧な業務は学習が回らない。
Resettable（やり直せる）：失敗しても巻き戻せるか。本番DBへの書き込みや顧客への送信など、不可逆な業務は最初の対象に向かない。
Efficient（評価コストが回る）：1回の評価が現実的なコストで済むか。評価に1日かかる業務では、ループが回らない。
この3軸を満たす業務、たとえば「定例レポートのドラフト生成」「コードレビューコメント生成」「メール下書き作成」あたりが最初の一歩に適している。
最小ループの組み立て：5つの手順
選定が済んだら、次の順で最小ループを組み立てる。
1つの業務を選ぶ：上記チェックリストで決定した業務に絞る。並行して複数走らせない。
Outcomeを書く：「何が達成されたら成功か」を1〜3行で言語化する。これが評価関数の根拠になる。
planner / generator / evaluatorの3役で回す：役割を明確に分け、1つのエージェントに兼務させない。境界が曖昧になると改善が効かなくなる。
evaluatorの評価関数を固定する：評価軸とスコアリング基準を文書化し、人間と機械で同じ関数を共有する。評価がブレると、改善方向もブレる。
Run LogとMemoryを残す：実行ごとに入力・出力・スコア・判断理由を記録し、次回のplannerとgeneratorの判断に反映する。
ここまでができれば、AI組織の最小ループは完成である。1人の天才プロンプトに依存せず、組織として学習が積み上がる構造になっている。
応用編へ：このループを「強く・広く」する
基礎編で作ったのは、あくまで1業務×1ループの最小単位だ。応用編では、このループを「強く」し、そして「広く」する。
強くする側では、評価関数を業務タイプごとに精緻化し（第10章）、暗黙知を形式知に変えて記憶を厚くする（第12〜13章）。広くする側では、複数業務を同じ仕組みに乗せ、組織横断のパイプラインへと展開する（第14章以降）。
まずは、明日の業務から1つ選び、Outcomeを1行書くところから始めてほしい。AI組織は、そこから自律的に育っていく。
応用編：AI組織を広げ、強くする設計
10. 評価関数の業務タイプ別設計：Type 1-4の使い分け
第5章で「評価関数は業務タイプによって姿を変える」と予告した。応用編の入口にあたる本章では、その分類体系を提示する。
評価関数を設計する出発点は、対象業務がどのタイプの評価に向いているかを見極めることである。
万能の評価関数は存在しない。業務の性質に合わない評価資産を持ち込むと、AI組織の改善ループはそのまま空転する。
分類の2軸：正解客観性 × 評価即時性
評価関数の設計は、次の2軸でマトリクスを描くと整理しやすい。
正解客観性軸：正解が客観的に定まるか、それとも主観・確率的にしか測れないか
評価即時性軸：成果の良し悪しを即時に判定できるか、それとも遅延・困難か
この2軸を直交させると、業務は4タイプに分かれる。
Type 1：客観的 × 即時
代表例はコーディングやデータパイプラインである。テストが通るか、回帰テストが落ちないか、カバレッジが基準を満たすかなど、機械が瞬時に判定できる評価資産が揃っている。評価資産としては、ユニットテスト、E2Eテスト、型チェック、リンタ、回帰スイート、ベンチマーク、SLOなどが該当する。AI組織との相性が最も良く、TDDとの組み合わせで改善ループが高速に回る領域である。
Type 2：主観・確率的 × 即時
代表例はコンテンツ生成、広告クリエイティブ、UIコピー、レコメンドの並び順である。
「正解」は単一には決まらないが、ユーザー反応というシグナルが比較的早く返ってくる。
評価資産としては、満足度スコア、保存率、クリック率、滞在時間、A/Bテストの統計的優位性、人手評価ルブリック、嗜好モデルなどが該当する。
鍵は、絶対値の良し悪しを問うのではなく、代理指標を束ねて確率分布として扱うことにある。
Type 3：客観的 × 遅延・困難
代表例は製造、ハードウェア設計、品質検証、安全クリティカル領域である。
最終的な「正解」は物理現象として客観的に決まるが、実際に作って壊して測るには時間と金がかかる。
評価資産としては、シミュレータ、デジタルツイン、有限要素解析、安全域マージン、故障モードFMEA、SIL/ASILなどの規格適合チェックが該当する。
実世界の評価が遅いぶん、仮想環境での代理評価をどれだけ精緻に作り込むかが勝負になる。
Type 4：主観・確率的 × 遅延・困難
代表例は経営戦略、投資判断、新規事業、M&A、政策立案である。「正解」は事後にすら確定しないことが多く、結果が出るまで数ヶ月〜数年かかる。
評価資産としては、仮説と前提の明示、意思決定ログ、複数シナリオ、リスク管理基準、IRR/NPVなどの感応度分析、敗北条件の事前定義などが該当する。
鍵は、結果の良し悪しではなく意思決定の質を評価対象に据え替えることにある。
ミスマッチがループを空転させる
業務タイプと評価資産がズレると、AI組織はもっともらしく動いて何も改善しない。典型例を二つ挙げる。
Type 2業務にType 1の評価を当てる：コピーライティングを「文法エラーゼロ」と「文字数ピッタリ」だけで評価する。テストは全て緑になるが、誰もクリックしないコピーが量産される。
Type 4業務にType 1の評価を当てる：投資判断を「DCF計算式が正しいか」だけで評価する。計算は完璧だが、前提シナリオが楽観的すぎることに誰も気づかない。
逆方向、つまりType 1業務に主観評価を当てるのも同様の空転を起こす。
コードレビューを「読みやすさ」の主観コメントだけで回すと、テスト通過という客観評価が見落とされる。
後続章への接続
次の第11章ではMemoryの深化を扱い、本章で示した4タイプそれぞれが「何を記憶として残すか」を支える。
さらに具体例として、第15章ではType 2（X投稿作成）を、第16章ではType 4（営業資料作成）を取り上げ、評価資産の組み立てと改善ループの設計を示す。
Type 1（コーディング）とType 3（製造・検証）は基礎編で繰り返し触れたパターンの延長として理解してほしい。
評価関数は「測れるもの」から逆算するのではなく、「業務のタイプ」から逆算する。これが応用編全体を貫く設計原則である。
11. Memory運用の深化：Dreamingと知見の鮮度管理
第7章でMemoryの基本構造を、第10章で業務タイプごとの評価軸を扱った。
本章のテーマは、その先にある運用課題、すなわち「Memoryを腐らせない」ことである。
Memoryは入れた瞬間が最も鮮度が高く、放置するほどノイズと古いルールが累積し、いずれ判断を歪める静かな毒へと変わる。
組織として無限にスケールさせるには、Memoryを書き込む仕組みと同じくらい、整理する仕組みを設計する必要がある。
その中核に据えるのが Dreaming である。Dreamingとは、過去のログとMemoryを一定の周期で振り返り、重複ルールの統合、矛盾ルールの解消、古いルールの隔離・削除を行う運用プロセスを指す。
人間でいえば「睡眠中の記憶整理」に相当するが、ここで強く釘を刺しておきたい。
Dreamingはモデルの重みを更新するものではない。LLM本体は変わらず、変わるのはMemoryというテキスト資産だけである。
学習しているように見えるのは、整理されたMemoryをプロンプトに注入し続けているからにすぎない。
この誤解を放置すると、「AIが勝手に賢くなる」という幻想で運用設計が雑になり、結果としてMemoryの劣化が早まる。
運用の必須項目は鮮度管理である。Memoryに登録する全エントリには、最低でも次の三つを併記する。
第一に 発効日（いつから有効か）、第二に 有効期限または再評価期日（いつまで有効か、いつ見直すか）、第三に 失効条件（どの状況が変わったら無効化するか）である。
たとえば「決算発表前のPRはレビュー優先度を上げる」というルールには「決算カレンダー運用が継続する限り有効」という条件を添える。
条件が崩れた瞬間にDreamingが検知し、ルールを退役させられる。期限のないMemoryは、いずれ必ず害になると考えてよい。
逆に、Memoryに入れてはいけないものも明確にすべきである。
第一に 一回限りのノイズ。
たとえば「先週のリリースで特定のリンターが誤検知を起こした」という偶発事象を恒久ルール化してはならない。
第二に 未検証の好み。「このレビュアーはコメントが短いほうが好きらしい」といった印象は、再現性が検証されるまでは個人メモに留める。
第三に 属人的な感覚。「ベテランAさんが違和感を覚えた」だけでルール化すると、Aさんの異動と同時に組織のMemoryが意味不明な遺物と化す。これらは観測ログには残してよいが、判断に効くMemoryには昇格させない、という線引きが要る。
整理して言えば、Dreamingは「Memoryに昇格させた知見を、定期的に棚卸しして退役させる運用」である。次章以降では、その逆方向、すなわち暗黙知や観測データを どうやってMemoryに昇格させるか――コンテキストレイヤーとknowledge curatorの役割を扱う。
12. 暗黙知を扱う：AI組織の入力を現場に広げる（コンテキストレイヤー）
第11章ではMemoryをどう整理し、何を残すかを扱った。整理棚としてのMemoryが整うと、次の課題は自然に「では、その棚に何を流し込むのか」に移る。AI組織が学習材料として何を入力できるか、その入口の広さが組織の伸びしろを決める。
整理された仕様だけでは足りない
AI組織を立ち上げる初期は、Issueや仕様書、設計ドキュメントといった「整った入力」だけで回せる。だが、業務の現場で本当に価値を持つ知識は、整った場所にはほとんど存在しない。判断の根拠、過去の失敗、顧客の真意、運用上の例外。こうした知識は、整形される前の発話やログとして現場に散らばっている。
AI組織は、最初から整理された仕様だけでなく、こうした暗黙知も入力として扱える設計にすべきである。整った入力に依存する組織は、現場の変化から切り離され、やがて陳腐化する。
暗黙知の入口
具体的に、AI組織が拾うべき暗黙知の入口は以下のようなものだ。
会議議事録
顧客インタビュー
営業ログ・商談メモ
レビューコメント（コード、ドキュメント、デザイン）
チャット（Slack、Teams、社内SNS）
個人の作業メモ・スクラッチパッド
失敗事例・ポストモーテム
業務マニュアル
設計書・アーキテクチャドキュメント
いずれも「人間が判断のために生み出した痕跡」である。これらを継続的に観測し、AI組織が扱えるコンテキストとして流し込む仕組みを、本書では コンテキストレイヤー（Context Layer） と呼ぶ。
コンテキストレイヤーの責務
コンテキストレイヤーは、現場で生まれる発話・ログ・反応を観測して取り込み、AI組織が後段で扱えるコンテキストに整える層である。
たとえば、議事録テキストの正規化、話者の匿名化、添付ファイルの参照解決、タイムスタンプとソースの付与、重複排除などがここに含まれる。
役割を一言で言えば、「現場とAI組織の境界に立ち、生のシグナルを観測して一次コンテキストとして整える層」だ。
ここで重要なのは、コンテキストレイヤーが判断ルールを作らないことである。判断ルール化は次章の変換パイプラインの責務であり、コンテキストレイヤーは入口の観測と整流に徹する。
運用設計の4つの柱
コンテキストレイヤーは強力な仕組みであるがゆえに、設計を誤ると組織のリスクを増幅させる。次の4点を運用設計の柱として明示的に扱う必要がある。
権限：どのソースに、どのエージェントが、どの条件でアクセスできるかをロール単位で定義する。
機密情報フィルタ：契約情報、未公開財務、顧客の機密データなど、組織として外に出してはならない情報をパイプライン手前で検出・遮断する。
個人情報除去：氏名、メールアドレス、電話番号、ID類を、用途に応じてマスキング・トークン化する。
保存期間：原文をいつまで保持するか、要約だけ残すか、いつ完全削除するかを保存ポリシーとして明文化する。
この4点を設計から外すと、コンテキストレイヤーは「現場の暗黙知をコンテキスト化する仕組み」ではなく「漏洩リスクを増幅する装置」になる。
技術的に動くことと、組織として運用できることの間にある最大の差分が、ここに集約される。
次章との責任境界
コンテキストレイヤーが担うのは、あくまで「何を観測し、どのように取り込むか」までである。
取り込んだ素材を「どんな判断ルールに変換するか」「どの粒度でMemoryに格納するか」は、次の第13章で扱う変換パイプライン（ナレッジパイプライン）の領域だ。
入口と変換を分離することで、ソースが増えても変換ロジックは安定し、変換方針を変えても入口の権限・フィルタ設計を壊さずに済む。
AI組織が現場の暗黙知を継続的に観測し、使えるコンテキストとして受け取るための最初のインフラが、このコンテキストレイヤーである。
13. 暗黙知を形式知にする：knowledge curatorとナレッジパイプライン
第12章では、暗黙知をAI組織に取り込むための「コンテキストレイヤー」を扱った。
会議、1on1、レビューコメント、顧客対話──そうした非構造化情報を、機密フィルタを通して時系列・話者・トピック付きの素材として保管するところまでが観測の責任範囲である。
だが、素材はそのままではAI組織の判断には使えない。本章では、観測された素材を「次回以降効くルール」へ変換する工程、すなわちknowledge curatorとナレッジパイプラインを詳述する。
本章の三大メッセージは、ナレッジパイプライン（6段階で気づきを再利用可能な判断に変える）、リアル起点（空想セオリーを生まない原則）、鮮度管理（形式知は永続ではないという前提）の3つである。
13.1 形式知化がAI組織の生命線になる理由
AIエージェント時代の本質は、「暗黙知 → 非構造化情報 → インサイト → 形式知 → ソフトウェア」という知識創造プロセス全体が、AIの守備範囲に入ったことにある。
これまで「人の頭の中にあるもの」を会議で共有し、議事録に落とし、誰かが標準化し、ようやくシステムに反映されるという長いリードタイムが必要だった工程が、AI組織では数日〜数時間のサイクルで回せるようになる。
ただし、それは「自動的に回る」わけではない。明示的な工程として設計しない限り、観測した素材は単なるログとして滞留する。
第12章のコンテキストレイヤーで観測して集めた素材は、再利用できる判断に変換しない限り、Memoryではなく「観測されただけのログ」でしかない。
形式知化されていない暗黙知は、AI組織にとっては事実上存在しないのと同じである。planner/generator/evaluatorは、自分が参照できる形に整っていないものを参照することができない。
「会議で議論された」「Slackで指摘された」「過去に失敗した」という事実があっても、それがプロンプトやrubricやMemoryに落ちていなければ、次回の意思決定は同じ前提を欠いたまま行われる。
逆に言えば、暗黙知を形式知に変える工程を組織として持てるかどうかが、AI組織の継続的な強さを決める。
generator/evaluatorの精度を1回上げる施策は誰でも考えられる。
しかし、組織が日々生み出す気づきを継続的に形式知化し、planner/generator/evaluatorに還流させる工程を持つことができれば、AI組織は時間の経過とともに勝手に賢くなる。
形式知化は、AI組織における「複利」の源泉である。
13.2 knowledge curatorの責任範囲
knowledge curator（以下、curator）は、コンテキストレイヤーから渡される非構造化情報を、AI組織が判断に使える形に変える役である。本書ではcuratorをgenerator/evaluatorと並ぶ独立した役割として位置付ける。3者の責任範囲を整理すると以下になる。
generator：今回の成果物を作る。出力は「成果物そのもの」。
evaluator：今回の成果物を採点する。出力は「合否と改善指示」。
curator：次回以降も使える判断ルールを作る。出力は「形式知（ルール・基準・反例集）」。
3者の最大の違いは時間軸である。generatorとevaluatorは「今回のタスク」に閉じている。
これに対しcuratorは「次回以降」を見ている。今日の議事録から、来週・来月・半年後も効くルールを抽出することがcuratorの仕事である。
curatorは「設計図書（rubric / Decision Rule / Anti-pattern）」を継続的に更新する役であり、単発の作業者ではない。
観測素材が増えるたびに知見候補を上げ、選別され、構造分解され、形式知化され、配置先のplanner/generator/evaluator/Memoryに組み込まれていく。
この一連の工程の駆動者がcuratorである。
責任分離の理由は1つだけ強調しておく。generator自身にcuratorを兼ねさせると、自分の出力を正当化するルールを後付けで作ってしまう。
「今回はこの判断でよかった」という結論ありきで設計図書が書き換わり、評価基準が緩む方向に作用する。
これは第3章でgenerator/evaluatorを分離した理由と同じ構造である。判断する役と、判断基準を更新する役は分ける。
13.3 ナレッジパイプライン：6段階で「気づき」を「再利用可能な判断」に変える
curatorの仕事は、暗黙知から形式知への流れを段階的に進める「ナレッジパイプライン」として設計する。
本書ではこれを6段階で定義する。各段階の担当・入力・出力・やること・注意点を以下に整理する。
Stage 1：観測（Observe）
担当：コンテキストレイヤー（第12章）
入力：会議議事録、1on1メモ、顧客対話、レビューコメント、失敗事例、Slack/Notionの議論ログ
出力：時系列・話者・トピックタグ付きの構造化素材
やること：機密情報フィルタ、個人情報除去、保存期間タグの付与
注意：観測の責任範囲は「取り込んで安全な形にする」までであり、知見抽出は次段階。ここで要約や解釈を入れると、後段で原文に戻れなくなる。
Stage 2：知見候補の抽出（Surface）
担当：curator（AI）
入力：構造化素材
出力：「これは知見ではないか」という候補リスト（短い要約 + 該当箇所への参照リンク）
抽出基準：再現性（同じ状況で同じ反応が複数回出ているか）／ルール外（既存ルールでは説明できない判断）／失敗構造（再発しそうな失敗パターン）／反例（一般論に反する事例）／キラめき（現場の暗黙知が言語化された瞬間）
注意：要約や一般論ではなく、「再現性のある具体的な判断・反応」を拾う。「丁寧な対応が大切」のような抽象表現は候補として上げない。
Stage 3：選別（Select）
担当：人間
入力：知見候補リスト
出力：採用候補（不採用は却下ログへ理由付きで残す）
選別基準：次回以降も使えるか／リアルな問題に根ざしているか／既存ルールと重複・矛盾しないか
注意：このStageを省略してAIに自動採用させると、空想ルールでMemoryが汚染される。人間の選別をボトルネックと感じるかもしれないが、ここを省略すると後段の構造分解・形式知化・配置の全工程が無駄になる。却下ログを残すのは、同じ候補が再度上がってきたときに二度手間を防ぐためである。
Stage 4：構造分解（Decompose）
担当：curator（AI）+ 人間レビュー
入力：採用された知見
出力：6要素に分解された構造化知見（成功条件 / 失敗条件 / 判断基準 / 避けるべき表現・挙動 / 具体例 / 反例）
やること：曖昧な「教訓」を、AIが参照したときに迷わない粒度まで分解する。
注意：曖昧な教訓のままMemoryに入れない。「顧客対応は丁寧に」ではなく、「どういう状況で／何を確認し／どう応答するか／逆に何を避けるか」まで降ろす。
Stage 5：形式知への変換（Formalize）
担当：curator（AI）+ 人間最終確認
入力：6要素に分解された構造化知見
出力：再利用可能な形式知（13.4で定義する6種類のいずれか）
やること：成果物形式を選び、配置先（planner/generator/evaluator/Memoryのどれか）と用途を明示する。
注意：1つの知見が複数の形式知になる場合がある。たとえば「過去に前提齟齬で手戻りした」という素材は、Anti-pattern（Memory）にもなり、Prompt Constraint（generator）にもなり、Review Checklist（evaluator）にもなり得る。
Stage 6：配置と検証（Deploy & Verify）
担当：curator + 設計責任者（人間）
入力：形式知
出力：planner/generator/evaluator/Outcome/rubric/Memoryに組み込まれた状態
検証項目：実際に呼び出されたか（呼び出しログがあるか）／品質が改善したか（rubric点数の変化、失敗パターン再発率）／既存ルールと矛盾しないか
注意：効果が出なければStage 4-5に戻して書き直す。「やった気」が最大の罠である。形式知を量産しても、配置されず・呼び出されず・検証されなければ、それは存在しないのと同じ。むしろMemoryのノイズになる分、害がある。
13.4 形式知の6つの成果物形式と配置先マトリクス
Stage 5で生成される形式知には、配置先と用途によって6種類の形式がある。これらを意識せずに「ルールを書く」と、どれにも当てはまらない宙吊りのドキュメントが量産される。形式と配置先を最初から明示することで、形式知は確実に呼び出されるようになる。
3点だけ補足する。
第1に、同じ知見素材が複数の形式知になることはむしろ自然である。
1つの失敗事例から、Prompt Constraint・Review Checklist・Anti-patternが同時に生まれることはよくある。
第2に、出典への参照は必ず残す。「2026-04-15議事録の発言ID:3-12」のようなトレース情報があれば、後で「このルールは今も有効か」を検証できる。
第3に、配置先と用途が決まっていない形式知はドキュメント滞留する。「いいことが書いてあるが、どこからも呼ばれないドキュメント」はAI組織にとって存在しないのと同じである。
13.5 「リアル起点」の原則：空想セオリーを生まないために
ナレッジパイプラインで最も汚染が起きやすいのは、Stage 2〜5でAIに「ルールを生成させる」誘惑に負けたときである。AIは一般論を流暢に書く。
だが、その一般論はあなたの組織の現場で起きたことに基づいているとは限らない。
これを本書では「空想セオリー」と呼び、Memoryに混入させてはならない最大の毒として扱う。
原則は1つで、形式知は実際に起きた問題・対話・失敗から抜き出す。コンテキストレイヤーが観測して集めた素材を起点にし、その素材に紐づかないルールは作らない。
「ベストプラクティス」型の一般論を生成するのは簡単だが、それはあなたの組織の現場とは無関係に存在し、Memoryを汚染する。
抽象表現の悪い例と良い例を並べる。
悪い例：「丁寧な対応が大事」
良い例：「顧客が『前回と同じでお願いします』と言った場合は、前回内容を読み上げて確認を取ってから着手する。理由：過去に前提齟齬で手戻りが発生した（出典: 2026-04-15議事録）」
両者の違いは情報量ではなく、検証可能性である。悪い例は誰も反論できない代わりに、誰の行動も変えない。
良い例は「いつ・誰が・何を言ったときに・どう動くか」が明示されており、generatorのプロンプト制約にも、evaluatorのチェック項目にも、そのまま転写できる。
さらに出典が残っているので、半年後に「2026-04-15の事案はもう発生しなくなったか」を検証することができ、ルールの失効判断が可能になる。
リアル起点の運用上のコツを2つだけ挙げる。
第1に、Stage 2の抽出はAIにやらせてよいが、必ず「該当箇所への参照リンク」を返させる。
原文に戻れない要約はStage 3で棄却する。第2に、Stage 5で形式知化するときは、必ず出典フィールドを必須項目にする。出典のないルールはMemoryに入れない。この2点だけで、空想セオリーの混入はかなり防げる。
13.6 形式知の鮮度管理と失効
形式知は永続ではない。市場・顧客・組織・モデル能力のいずれかが変われば、過去の判断基準は古びる。
半年前に書いたWriting Ruleが、新しいモデルでは過剰な制約として働き、出力品質を逆に下げているということは普通に起きる。
そのため、すべての形式知にメタ情報を持たせる。最低限必要なのは以下である。
作成日：いつ追加されたルールか
最終検証日：最後に「今も効いているか」を確認したのはいつか
失効条件：何が変わったらこのルールを見直すか（例：「新モデルでハルシネーション率が10%を下回ったら」「該当顧客との取引が終了したら」）
そして、第11章で扱ったDreaming運用の中で定期的に棚卸しを行う。
古い前提のルールを失効させ、矛盾するルールを統合し、長期間呼び出されていない未使用ルールを削除する。
鮮度管理がないMemoryは、時間が経つと「ノイズの倉庫」になる。
ルールの数が増えれば、generatorのコンテキストが膨らみ、矛盾する指示が混入し、出力品質はむしろ下がっていく。
形式知化と鮮度管理は1セットだと理解する必要がある。
13.7 13章固有の失敗パターン
本章の文脈で頻出する失敗パターンを6つにまとめる。第18章で扱う組織レベルの失敗5分類とは別に、curator運用に固有の落とし穴として位置付ける。
要約で終わる：議事録AI要約をそのままMemoryに格納してしまう。要約は知見ではない。Stage 2〜5を経ていない素材を形式知扱いすると、Memoryは「議事録のコピーの山」になる。
構造分解を飛ばす：Stage 4を省略し、箇条書きのままMemoryに保存する。AIは曖昧な箇条書きを「条件分岐できる判断ルール」として使えない。
配置先を決めない：Stage 5で形式に分類せず、ドキュメントとして保存して終わる。どこからも呼ばれず滞留する。
検証しない：Stage 6の検証を省く。ルールを増やすだけ増やし、効いているかを測らないので、Memoryが膨張する一方で品質は上がらない。
空想セオリー混入：リアル素材なしにAIに一般論を生成させる。13.5で述べた最大の毒。
鮮度管理を放棄：失効条件を決めない。古いルールが新しいルールと矛盾し、generatorが混乱する。
これらはどれも、ナレッジパイプラインを「ルール量産プロセス」と誤解したときに起きる。ナレッジパイプラインは量産装置ではなく、品質管理装置である。
13.8 13章まとめ
本章で押さえるべきポイントを再整理する。
形式知化は、暗黙知を「次回以降効くルール」に変える工程であり、AI組織における複利の源泉である。形式知化されていない暗黙知は、AI組織にとっては存在しないのと同じ。
knowledge curatorは、generator（今回の成果物）／evaluator（今回の採点）とは時間軸が異なり、「次回以降の判断ルール」を作る役として責任を分ける。generatorに兼務させると、自己正当化のルールが生まれる。
ナレッジパイプラインは6段階：観測 → 候補抽出 → 選別 → 構造分解 → 形式知化 → 配置と検証。選別と検証を省くと、Memoryは確実に汚染される。
6つの成果物形式（Writing Rule / Decision Rule / Review Checklist / Prompt Constraint / Evaluation Rubric / Anti-pattern）を、配置先と用途を明示して使い分ける。形式と配置先が決まっていない形式知は滞留する。
リアル起点でないと空想セオリーになる。出典のないルールはMemoryに入れない。
鮮度管理と失効ルールがないと、Memoryはノイズの倉庫になる。Dreaming運用で定期棚卸しを行う。
ここまでで、AI組織が判断するための「設計図書」を継続的に更新する仕組みを論じた。
次の第14章では、本章までに登場したplanner/generator/evaluator/curatorといった役割を、単一エージェント内のプロンプト分割から、物理的に分離されたMulti-agentへと移していく話を扱う。
役割をどう物理的に切るかは、責任分離と通信コストのトレードオフであり、AI組織のスケール限界を決める設計判断である。
さらに第17章では、本章のナレッジパイプラインを「議事録駆動」という具体的なユースケースに落とし、実際の運用例として詳述する。
14. Multi-agent化：役割分離から責任境界の分割へ
基礎編の第3章で示した planner / generator / evaluator の三役は、あくまで「責任の分離」であった。
同じ文脈・同じプロセスの中で、役割ラベルを切り替えながら回すだけでも、自己強化ループは成立する。
ここまでの応用編で議論してきた評価関数の設計、暗黙知の形式知化、コンテキストレイヤー、knowledge curator までを、最初は一つのエージェントの中で「役割を切り替える」形で実装してもよい。
しかし、ある規模を超えると、責任の分離だけでは破綻する。
調査の途中で読み散らかした50ページ分の中間結果が generator の文脈を圧迫し、評価基準が生成の都合に引きずられ、過去の学習が新しい仮説で上書きされる。ここで必要になるのが「物理分割」である。
責任分離と物理分割の違い
責任分離とは、一つのプロセスの中で「いま何の責任を担っているか」を切り替えることをいう。
物理分割とは、独立した文脈、独立した system prompt、独立したツール権限、独立した実行ライフサイクルを持つエージェントとして役割を切り出すことをいう。前者は思考のモードを切り替えるだけだが、後者はインスタンスそのものを分ける。
物理分割の利点は三つに集約できる。
第一に、途中で捨てるべき調査文脈を本流に持ち込まない。researcher 用のエージェントが100件のドキュメントを読んでも、generator にはその要約だけが渡る。
第二に、責任ごとに評価基準とツール権限を分けられる。
evaluator には書き込み権限を与えず、curator にしか learnings への追記を許可しない、といった分離が可能になる。第三に、system prompt とモデル選定を責任ごとに最適化できる。
分割の基本単位
応用編で扱う分割の基本単位は四つである。
planner（タスク分解と順序づけ）、generator（成果物の生成）、evaluator（rubric による評価）、そして第13章で別役割として提示した knowledge curator（実行痕跡から再利用可能な知識への昇華）である。
調査が重い領域では researcher、複数 generator の出力を束ねる integrator を加えることもある。要点は、調査・生成・評価・統合・知識化という五つの責任を、文脈もツールも分けてよいかという観点で見直すことである。
分割しないほうがよい場合
逆に、分割が害になる場面もある。タスクが小さすぎる場合、エージェント間の往復コストが本来の処理コストを上回る。
直列依存が強く、generator の中間状態を evaluator がリアルタイムに参照する必要がある場合、文脈の分断は同期コストとして跳ね返る。
さらに、創造的な仕事のように「生成と評価が同じ思考の中で揺れ動く」ことが本質的な工程では、責任の物理分割は思考そのものを壊す。
判断基準：速さではなく、責任と評価基準
ここで最も重要な原則を述べる。Multi-agent 化の判断基準は、速くなるかではなく、責任と評価基準が分けられるかで判断する。
並列実行による高速化は副作用であって目的ではない。同じ評価基準・同じ責任で動く二つのエージェントを並べても、それは単なる多重化であって組織化ではない。
逆に、たとえ直列にしか動かなくても、責任境界と評価基準が分かれていれば、それは組織として機能する。
第15章以降では、この判断基準に従って具体的なパターンを示していく。
15. 具体例：X投稿作成AI組織（Type 2 × 評価関数の設計が焦点）
ここまで議論してきた「業務タイプ別の評価設計」「コンテキストレイヤー」「knowledge curator」「Multi-agent化」を、X（旧Twitter）の投稿作成業務に統合した具体例として示す。
AI関連ニュースや登壇内容をネタに、日本語Xスレッドを日々量産する業務を想定する。
業務タイプ：Type 2（主観・確率的×即時）。何が「良い投稿」かは事前に決まらず、読者の反応によって事後的に判明する。
焦点：評価関数を代理指標でどう設計するか。クリック率・保存率・コメント傾向といった観測可能な代理指標と、内的rubric（正確性・分かりやすさ・実務示唆・誇張の有無）の組み合わせで「読者に刺さる投稿」を近似する。
Input：AI関連ニュース、自分の登壇内容、過去投稿、読者の反応ログ（保存・引用・コメント）。
構成
コンテキストレイヤー：投稿後の保存率、反応コメント、伸びなかった投稿、読者が引っかかった表現を継続的に収集する。
単なる数値だけでなく「コメントで多用された言い回し」「保存された投稿の構造」といった半構造データもここに集約する。knowledge curator：観測ログから「読者に刺さった切り口」「避けるべき誇張表現」「保存されやすい構成（結論先出し／3点列挙／対比構造など）」を抽出し、Memoryに形式知として落とし込む。
生ログのままでは次の生成に効かないため、curatorによる蒸留が不可欠である。planner：元情報（ニュース・登壇内容）の論点を整理し、読者の関心軸との交点で「今回の切り口」を決める。
ここでMemoryの「刺さった切り口」を参照する。generator：plannerの切り口に沿って、日本語Xスレッドを作成する。冒頭フック、本論、結論の構造、文字数制約、絵文字の使い分けなどを担う。
evaluator：投稿前の事前評価として、正確性、分かりやすさ、実務示唆、誇張の有無を内的rubricで採点する。
投稿後は代理指標（保存率・コメント質）でフィードバックを返す。事前rubric × 事後代理指標の二段構えがこの業務の肝である。Memory：読者の反応、保存されやすい構成、避けるべき表現を蓄積する。
短期Memory（直近の反応傾向）と長期Memory（恒常的に効く切り口・NG表現）を分けると劣化しにくい。
評価関数の設計ポイント
Type 2業務では「正解」が存在しないため、評価関数を一本の数式で書こうとすると必ず破綻する。
X投稿の場合も、保存率だけを最適化すれば過度に網羅的な投稿に偏り、コメント数だけを追えば煽り表現が増える。そこで本例では、
投稿前：内的rubricで誇張・不正確・冗長を弾く（下限を担保するゲート）
投稿後：代理指標をコンテキストレイヤーへ流す（上限を伸ばす学習信号）
curatorが両者を突き合わせ、Memoryに「rubricを通ったが伸びなかった投稿」「rubricでは平凡だが伸びた投稿」のパターンを蓄積する
という三層構造で評価関数を運用する。これにより、rubricは保守的すぎず、代理指標は煽りに振れすぎない、という均衡が取れる。
章末
同じ枠組み（コンテキストレイヤー → curator → planner → generator → evaluator → Memory）は、X投稿に限らず、ブログ生成、営業メール作成、UIコピー改善など、Type 2の創作系業務全般に展開可能である。
代理指標と内的rubricの組み合わせ方を業務ごとにチューニングすればよい。
次章ではこれを応用し、評価信号が遅延するType 4の業務として、営業資料作成AI組織の具体例を見ていく。
16. 具体例：営業資料作成AI組織（Type 4 × Human Review境界の設計が焦点）
業務タイプ：Type 4（主観・確率的 × 遅延・困難）
焦点：どこまで自動化し、どこで人間が止めるか。すなわち Human Review の境界設計
Input：顧客情報、商談ログ、業界ニュース、競合資料、過去提案の勝敗理由
営業資料作成は、第15章で扱ったType 2のX投稿作成とは性質が根本的に異なる。
X投稿は保存率・コメントといった反応が翌日には返ってくるが、営業資料は 商談結果が出るまで数週間から数ヶ月かかる うえ、勝敗理由は競合動向、担当者の異動、予算サイクル、社内政治といった多変量に依存する。
「この資料がよかったから勝った」と単一要因に帰着できることはまずない。これがType 4の本質的な難しさである。
評価信号が遅延し、しかも因果が曖昧な領域では、AI組織の設計思想を切り替えなければならない。
evaluatorに完全な品質判定を担わせるのは諦め、即時評価可能な範囲のみを任せる。
そして事後にしか正解が分からない領域、すなわち事業リスクを伴う判断は、Human Reviewが明示的に引き受ける。これが本章のメッセージである。
各レイヤーの役割
コンテキストレイヤーは商談現場の生データを観測して拾う。顧客の発言原文、提案中に反応が悪かったスライド、逆に深く食いついた課題仮説、競合との比較で出た反論。
録画・録音や商談メモから機械的に抽出し、勝敗ラベル（受注／失注／保留）と紐づけてストックする。
Type 4では「何が刺さったか」の特徴量は事後にしか集まらないため、観測の網を粗くしないことが効く。
knowledge curator はコンテキストレイヤーが溜め込んだ生データを形式知化する。業界別の典型的な痛み、よく出る反論パターン、意思決定者の職位別関心事（CFOはROI、現場部長は運用負荷、情シスはセキュリティ）といった軸で整理する。
ここは時間をかけてでも構造化する価値がある。後段のplanner・generatorの精度を左右する母艦になるからだ。
planner は今回の顧客・業界・競合を調べ、curatorの形式知と突き合わせて、課題仮説とソリューションの対応関係を設計する。
generator はその設計に沿って営業資料の構成を出力する。
evaluator はここで踏みとどまる。即時評価できるのは、顧客理解の整合性（商談ログの発言と資料の課題仮説が矛盾していないか）、論理の説得力（課題→解決→効果の流れが破綻していないか）、次アクションの明示、そして 誇張リスクの検知（過去提案にない実績や数値が混入していないか）まで。
「この資料で受注できるか」は判定不能なので、判定範囲外と明示する。
Human Reviewが引き受ける高リスク領域
Type 4で人間が必ず止めるべきは、間違えたときに事業損失が大きく、かつ事後修正が困難な領域である。具体的には次の四つを境界として設定する。
価格：割引率、初期費用、ボリュームディスカウントの提示。一度提示した価格は撤回できない
契約：契約期間、解約条件、SLA、責任範囲。法的拘束力を持つ表現はAI出力をそのまま使わない
法務：知財表現、競合比較の根拠、業法・景表法に触れうる文言
実績表現：「導入企業◯◯社」「◯◯%改善」といった数値実績、固有名詞による事例引用。誇大表現は信頼を一発で失わせる
これらの箇所はgenerator出力でフラグを立て、Human Reviewなしには外に出さないゲートを設ける。
逆に言えば、それ以外の構成・課題整理・ストーリーラインはAI組織側で完結させてよい。境界が引かれていないAI組織は、安全側に倒して全件レビューになるか、危険側に倒して炎上するかのどちらかに陥る。
境界の明示こそがType 4におけるスケール条件である。
次章では、コンテキストレイヤーをType 2とType 4のハイブリッド領域でどう応用するかを扱う。
17. 具体例：議事録駆動の知見抽出AI組織（コンテキストレイヤーの応用が焦点）
業務タイプ：Type 2と4のハイブリッド。知見の質は、抽出した瞬間ではなく、後の業務で「あの判断軸が効いた」と再利用された時点で遅れて判明する。
焦点：コンテキストレイヤーをどう設計し、組織に散らばる暗黙知をAI組織の入力に変えるか。
Input：会議議事録、1on1メモ、顧客ヒアリング記録、SlackやNotionの議論ログ、レビューコメント。
第12章で導入したコンテキストレイヤーと、第13章で整理したナレッジパイプラインを統合する具体例が、議事録駆動の知見抽出AI組織である。
Type 2（記事生成のような長期で質が判明する業務）と、Type 4（FAQや運用ルールのように既存知識を再構成する業務）を行き来するハイブリッドであり、コンテキストレイヤーの設計品質がそのまま組織の学習速度に直結する。
observerとcuratorの役割分担
本章では、コンテキストレイヤーで観測を担うエージェントをobserverと呼ぶ。
observerは、社内に流れる議事録・1on1メモ・顧客ヒアリングログを継続的に読み続けるエージェントである。
その仕事は判断ではなく、「これは知見の候補ではないか」という気づきを生成することに限定される。
具体的には、「複数の会議で繰り返し言及されている論点」「ベテランが暗黙に使っている判断基準」「顧客が困っている文脈」「過去の失敗の言い換え」といった信号を拾い、候補リストとして書き出す。observerは粒度や用途を判断しない。
雑多であっても、捨てずに拾う側に振る。
curatorは、その候補を受け取り、分類と棄却を担う。判断ルール、失敗パターン、記事ネタ、社内ナレッジ、改善Issueといったカテゴリに振り分け、重複や陳腐化したものを統合・廃棄する。
observerが「広く拾う」設計であるのに対し、curatorは「厳しく絞る」設計にする。
役割を明確に分けないと、observerが自己検閲を始め、暗黙知の入口が閉じてしまう。
generatorとevaluatorの責務
generatorは、curatorが選び抜いた知見を成果物に変換する。
記事、チェックリスト、評価rubric、FAQ、運用ルールなど、消費される形式は知見の種類によって異なる。同じ知見が、新人向けにはチェックリストになり、エキスパート向けにはrubricになるという複線化が起きる。
evaluatorは、出力物を三つの観点で評価する。
第一に、現実の問題に根ざしているか。抽象論や一般論に流れていないか。
第二に、機密情報や個人情報、未公開の戦略が混入していないか。議事録を入力にする以上、ここの守りは絶対条件である。
第三に、再利用可能な粒度になっているか。具体すぎてその案件にしか使えない、あるいは抽象すぎて何も指示できない、という両極を弾く。
Memoryの役割
Memoryには、繰り返し現れる判断、頻出する顧客理解、組織固有の文体ルール、過去に揉めた表現や避けるべき言い回しを蓄積する。
これにより、次回以降のobserverは「既知の知見」をスキップして新しい信号に集中でき、curatorは過去の分類との一貫性を保てる。
Memoryが厚くなるほど、新しい議事録から拾える「未知の知見」が際立つようになる。
価値：会議を学習材料に変える
多くの組織で、会議は「終わったら忘れられる情報」になっている。本章のAI組織は、その会議を、組織が継続的に学習するための入力に変える装置である。
コンテキストレイヤーが機能している限り、議事録を蓄積するほど判断ルールやFAQは厚くなり、組織は静かに賢くなり続ける。
次の第18章では、こうした組織が陥りがちな失敗パターンを五つに整理し、最終の第19章で全体を総括する。
18. 失敗パターン：AI組織化でやりがちな間違い（5分類）
第1〜17章で組み立てた設計は、現場に置いた瞬間に崩れる。崩れ方には型がある。
ここでは、AI組織化の現場で繰り返し観測される失敗を5つに分類して整理する。
いずれも「設計が悪い」というより、「設計の前提を誤読している」「設計の一要素を抜いている」ことで発生する構造的な失敗である。
Outcome選定の失敗（そもそも何をAI組織化するか）
これは第4章「Outcome設計」と第9章「業務選定（Rewardable / Resettable / Efficient）」の失敗である。
そもそもOutcomeに価値がない：最も気付きにくく、最も致命的な失敗である。
価値があると思い込んでいる業務をAI組織化してしまい、評価関数もエージェント設計も完璧なのに、業務そのものに需要や意味がないため成果が出ない。
エージェントは回り、評価スコアも上がり、ログ上はすべて健全に見える。だが誰もその出力を使っていない。
技術的にうまく回っているように見える分、組織は「もう少しチューニングすれば成果が出るはずだ」と錯覚し続け、半年単位で時間と予算を溶かす。
AI組織化する前に「この業務の出力は誰が、なぜ、どれくらいの頻度で必要としているのか」を必ず問い直す。
需要の存在を一次情報で確認できない業務は、どれだけ自動化しても価値を生まない。自動化対象を「仕様化しやすいか」だけで選んでしまい、「観測できるか」「評価できるか」を見落とす。
仕様化はできても評価関数が組めない業務は、AI組織化の対象としては早い。Rewardable / Resettable / Efficientの3軸での業務選定をスキップし、いきなりエージェント設計に入る。
3軸を満たさない業務は、改善ループが回らず、組織として学習できない。
Outcome設計の失敗（選んだ業務の成功条件をどう言語化するか）
これは第4章「Outcomeの5要素」の失敗である。
「良い成果物とは何か」をOutcomeとして言語化できないまま、エージェントだけ先に組む。
結果として、エージェントは何を最大化すべきか分からないまま動き続ける。Must Pass、Quality、Constraints、Failure Conditions、Scoring Rubricの5要素のうち、いずれかが抜けたまま運用する。
特にFailure ConditionsとScoring Rubricの欠落は、「合格はしているが価値が低い」成果物を量産する原因になる。Outcomeを定めないまま複数エージェントを走らせる。役割分担も評価もOutcomeに紐付かないため、エージェント間の議論が発散し、合意形成のコストだけが膨らむ。
評価関数の失敗
これは第5章「評価関数の基礎」と第10章「業務タイプ別の評価設計」の失敗である。
evaluatorが何をどう評価するのか、評価指標・評価基準・合格ラインに落とし込めない。
評価が「LLMに良し悪しを聞く」だけになり、再現性とフィードバック品質の両方が崩れる。業務タイプに合わない評価資産を使う。主観的な仕事を厳密テストだけで評価する、遅延評価の仕事を即時スコアだけで判断する、といったミスマッチが典型である。
評価対象と評価手段の整合は、第10章で扱った業務タイプ分類に立ち返って点検する。generatorに自己採点させる。生成と評価は責任を分けるのが原則であり、自己採点はバイアスの温床になる。
評価基準を途中で変えて、改善したように見せる。スコアが上がったのではなく、基準が下がっただけ、という現象が起きる。
Rubricの変更履歴は必ず残し、変更時はベンチマークを再走させる。
Memory・暗黙知運用の失敗
これは第7章「Memory管理」、第11章「Dreaming」、第12章「コンテキストレイヤー」、第13章「暗黙知の形式知化」の失敗である。
暗黙知を単なる議事録要約で終わらせ、判断ルールやrubricに変換しない。要約は記録にはなるが、次のエージェントが参照しても判断は変わらない。
現実の問題を起点にせず、もっともらしい一般論だけをMemoryに入れる。
一般論はノイズになり、参照コストばかり上げる。Memoryは「実際の失敗または成功の起点」に紐付いている必要がある。Memoryに一回限りのノイズや未検証の好みを入れる。個人の趣味や偶発的な事象が組織の判断ルールとして固定化され、長期的に判断を歪める。
機密情報、個人情報、責任境界を決めないままコンテキストレイヤーを広げる。観測範囲の拡大は権限と責任の拡大とセットで設計しないと、後から取り返しがつかない。
組織設計の失敗
これは第3章「3役の責任分離」、第8章「人間の役割」、第14章「Multi-agent化」の失敗である。
Multi-agent化すれば品質が上がると思い込む。役割が曖昧なまま数だけ増やしたMulti-agentは、合意コストが品質向上分を食い潰す。
人間レビューが必要な領域まで完全自動化する。責任境界・説明責任・最終判断を持つべき領域を自動化すると、事故が起きたときに誰も止められない。
役割分離（責任の分け方）と物理的なエージェント分割を混同する。責任分離は1エージェント内のプロンプト設計でも実現できる。逆に、責任設計なしにエージェントだけ分割しても、責任は分かれない。
ここまでの5分類は、いずれも「設計の何かを省いた」ことで生まれる失敗である。第19章では、本記事全体を振り返り、AI組織を継続的に成長させるための要点をまとめる。
19. まとめ：AI組織を設計できる人が、次の競争力を持つ
ここまで18章にわたって、評価、役割分担、記憶を軸にAI組織を組み立てる方法を見てきた。最後に強調したいのは、これからの競争力の源泉が「AIを使う力」から「AIが成果を出し続ける制度を作る力」へと、はっきり移っているという事実である。プロンプトの巧拙やツールの選定は重要だが、それは入り口に過ぎない。勝敗を分けるのは、AIが日々生み出すアウトプットを評価し、改善し、組織の知として残し続けられるかどうかである。
AI導入のコアは、手順の仕様化ではなく評価設計である。何を成果と呼び、誰がどの基準で良し悪しを判定するのか。これが曖昧なまま手順だけを精緻に書いても、AIは速度を上げて品質をばらつかせるだけだ。前章で示した失敗パターンの多くも、根を辿れば「評価関数の不在」に行き着く。
最初の一歩は、派手な仕掛けではない。Outcome（何を成果とするか）、evaluator（誰がどう評価するか）、Run Log（実行と結果の記録）。この3つを定義するところから始めればよい。逆に言えば、この3つがないままエージェントを増やしても、組織として学習しない作業者の群れができるだけである。
基礎構造ができたら、次の階層に進む。業務タイプに合った評価設計（定型処理か、判断業務か、創造業務か）を選び分け、現場の暗黙知を形式知に変える仕組みを足していく。エージェントを増やすのは、その後でよい。順序を間違えてはならない。評価して改善するループのないところに人員を増やしても、混乱が増えるだけだ。
AI組織の本質は、知識化、役割分担、評価、改善、記憶という5つの動作を止めずに回し続けることにある。これは一度作って終わる仕組みではなく、業務とともに育てていく生き物に近い。完璧な初期設計より、回し始めて改善できる最小構成のほうが価値がある。
第18章で示した通り、AI組織づくりには典型的な失敗がいくつもある。それでも作る価値がある、と本書は言い切りたい。なぜなら、AIを個人の道具として使う時代は終わりつつあり、AIを制度として運用できる組織だけが、これからの数年を加速できるからだ。本書を閉じたあと、まずはOutcomeを一つ書き出すところから始めてほしい。AI組織の設計図は、そこから組み上がっていく。
本記事が「自分の現場でも最初の一回転を回してみよう」と思うきっかけになれば、書いた甲斐があります。もし少しでも参考になったと感じていただけたら、「いいね」 を押していただけると励みになります。また、同じ課題感を持つ同僚やチームメンバーがいれば、ぜひ シェア していただけると嬉しいです。
