【IDO】第8回:なぜAARは「査問会」になるのか?――偏流する解釈空間を「再収束」する組織OSの設計
組織は、自由を与えれば漂流する。
しかし、縛りすぎれば停止する。
AARとは、偏流した解釈空間を再び収束させるための「組織学習エンジン」である。
"From Control to Intent"
── 組織OSを「企図」で再起動する。
(絵画出典:Nocturne: Blue and Gold – Old Battersea Bridge(1875), James Abbott McNeill Whistler, Public Domain)
【免責事項】
本稿は筆者個人の見解であり、所属組織の公式見解を示すものではありません。また、記載内容は公開情報および一般化・抽象化された概念に基づいています。
前回「なぜ企図は偏流するのか?──オートポイエーシスから読み解く組織の自己再生産」において、私たちはシステム論の冷徹な結論に達しました。
組織とは「コミュニケーションの自己再生産サイクル(オートポイエーシス)」であり、外部から直接コントロールすることはできません。
どれほど優れた上位企図(Intent)を投入しても、現場という自律的システムに触れた瞬間から独自の内部論理で再解釈され、必然的に偏流を始める――すなわち「Intent Drift(企図偏流)」の発生です。
最も不気味な病理は、組織の全員が「顧客中心」などと同じ言葉を使いながら、認識している世界が完全に乖離していく「Intent Driftの累積」にありました。
では、避けられないDriftの引力に対して、私たちはどのようにして組織を統制するのではなく、動的に調律(オーケストレート)し続ければよいのでしょうか。その解決の鍵を握るのが、多くの日本企業が導入しながらも機能不全に陥らせているフレームワーク「AAR(After Action Review:行動後レビュー)」を窓口とした、組織OSの再設計です。
1. 「IntentなきAAR」という構造的無理ゲー
「今回のプロジェクトの振り返りを始めます。次に向けて、忌憚のない意見を出してください」
会議室に流れる重苦しい沈黙。ようやく出た発言は、「次回はコミュニケーションを密にします」「確認を徹底します」といった、誰も傷つかない形式的な感想戦です。あるいは最悪の場合、「なぜあの時、この確認を怠ったんだ?」「誰の判断だ?」と、個人のミスを突き止める「犯人探し(査問会)」へと変質していく――。
多くの組織が、米軍や航空業界などの高リスク組織で発展した学習手法であるAARを導入しています。しかし、やればやるほど組織が萎縮し、同じ失敗を繰り返すのはなぜか。
それは、多くの組織で「Intent(企図)」が不在のまま、AARというアプリを動かそうとしているからです。
ここで、本連載におけるIntentの定義を、理論的に厳密に固定しておきましょう。
IDOにおけるIntent(企図)とは、現場が自ら意味生成を行う際の「解釈空間を方向付ける制約条件(Constraint)」である。そしてこの制約条件は、実務においては多くの場合、その制約を満たすための「表現・運用仮説」として実装される。
単なる数値目標や行動指示ではなく、現場の解釈の「河道(方向性)」を規定するこのインフラがない組織でAARを行うことは、構造的に不可能なのです。
2. 中間管理職が陥る「合理的自己防衛」と確認文化の正体
ここで、中間管理職が日々引き裂かれている矛盾に耳を傾けてみましょう。
「『自分で考えて動け』と言われるから動いた。
そしたら『なぜ事前に確認しなかったんだ』と怒られる。
だから次からは慎重に『確認をお願いします』とお墨付きをもらいに行くと、今度は『いちいち指示を仰ぐな、自分で決めろ』と呆れられる。
一体、どうしろというんだ……」
この、現場を精神的に追い詰める「確認文化」の正体こそが、実はIntentの不在、あるいはAARの機能不全を地続きで引き起こしている真犯人です。
しかし、ここで中間管理職を責めてはいけません。中間管理職もまたシステムの産物です。Intentという「解釈の枠組み」が霧の向こうに隠れている以上、減点リスクを避けるために「お墨付き(確認)」を求めるのは、システム内で生き残るためのきわめて合理的で賢明な判断だからです。
これは個人のマインドセットのせいではなく、組織の「アーキテクチャ(構造)」の問題です。古い「正解主義OS」の上に、高度な「学習アプリ(AAR)」を無理に乗せようとするから、次のような仕様のミスマッチ(バグ)が起きるのです。
1. OS:意思決定原理の不全
Intentの不在:上意下達のまま「Intent(制約条件)」が言語化されず、現場に共有されない。
2. エラー1:自律性の停止
解釈空間の野生化
メンバーが自律的に動く「任務指揮(Mission Command)」が不可能になり、各自の解釈空間がバラバラに漂流し始める。
3. エラー2:合理的自己防衛
お墨付きの要求
ノーヒントの暗闇で転んで減点されるのを防ぐため、現場はあらゆる行動に「確認(お墨付き)」を求める。
4. エラー3:儀式化するコミュニケーション
責任の分散
会議は意思決定の場ではなく、誰も責任を取らないための「正解確認の儀式」と化す。
5. アプリの衝突:査問会への変質
OSの限界
その状態のまま「AAR(活動後レビュー)」を動かそうとするため、ズレた解釈の検証ではなく、単なる「犯人探し」になり中間管理職が疲弊する。
3. AARの本質は「正解の答え合わせ」ではなく「差分の観測」である
では、本来のAAR(活動後レビュー)とはどういう営みなのでしょうか。その構造は驚くほどシンプルです。
1. 何を目指していたのか?
(Intent:制約条件 / それを実装するための仮説)
2. 実際には何が起きたのか?
(Result:結果・現実)
3. なぜその「差分」が生まれたのか?
(Analysis:分析)
4. 次はどう修正するのか?
(Action:対策・更新)
すべての出発点は「1. Intent」です。システム論的に言えば、AARとは決して「誰が正しかったか」を判定する裁判ではありません。AARとは、Intentを実装するために置いた仮説と、現実とのズレを観測する学習センサーなのです。
ここで、よくある疑問が浮かびます。「なぜ、一般的なKPIレビューやPDCAサイクルでは駄目なのか?」という問いです。
世にあるマネジメント手法と、IDOが定義するAARとの間には、追っている対象に決定的な違いがあります。

本来、PDCAもまた仮説検証の循環であるはずですが、多くの実務現場では「計画(P)通りに行動(D)したか」のチェックに終始しがちです。
一方で、AARが扱うのは行動の成否そのものではなく、「私たちが世界をどう捉えていたか(Intentという制約条件を満たすための仮説)と、現実の結果とのズレ」です。事前に解釈の枠組みがあるからこそ、結果が予想と違ったときに「どの前提が違っていたのか」という、システムを健やかに変容させるための差分学習が可能になるのです。
4. IDOの全体像:組織学習サイクルの理論モデル
この「Intent」から始まる差分の学習こそが、IDO(Intent-Driven Orchestration)が提唱する組織OSのコアエンジンです。
ここで、これまで断片的に語られてきた「三種の神器」が、単なる情報共有のツールとしてではなく、「動的な組織学習サイクルの理論モデル」*として一本の美しい円環を結びます。
Intent(企図):
現場の「解釈空間」を方向付ける高次の制約条件
COP(統一状況図):
Drift(漂流)を客観的に測定可能にするための前提舞台
AAR(学習装置):
観測面(COP)に現れた現実とのズレを感知し、再収束させる仕組み
ここで極めて重要なのは、AARを駆動させる前段にある「COP(Common Operating Picture:統一状況図)」の存在です。
なぜ、AARの前にCOPが必要なのか。
それは、Driftを正確に観測するためには、まず「同じ環境」を観測している必要があるからです。
それぞれが異なる情報源、異なる状況認識、異なる前提条件でバラバラに行動している場合、事後に現れた結果のズレが「解釈の差分(Drift)」なのか、それともそもそも「見ている対象(環境)の差分」なのかが判別できなくなります。
COPの本質は、単なる情報のシェアではありません。ズレが『解釈の差』なのか『見ているものの差』なのかを峻別し、Driftというエラーシグナルを正しく測定可能にするための「統一状況図」なのです。
【 1. Intent の提示 】
解釈空間を方向付ける制約条件
▼
【 2. COP の構築 】
統一状況図:同じ環境をリアルタイムに観測
▼
行動
現場の自律的作動
▼
【 3. COP 上で「差分」を可視化 】
(必然として発生した Drift の感知)
▼
【 4. AAR の作動 】
解釈枠組みと現実の「差分」を学習・分析
▼
【 5. Intentを実装する仮説の更新 】
高次の制約条件を満たすための表現モデルを洗練
└─────────→【 継続的収束 】(1へ戻る)
ここで、実務における極めて重要なパラダイムを補足しておきます。
AARを通じて「更新」されるのは、Intent(制約条件としての高次の企図)そのものではありません。更新されるのは、そのIntentを満たすために現場が置いた「表現仮説(運用モデル)」です。
例えば、Intentが「顧客価値を最大化する」という不変の制約条件であるならば、AARによってアップデートされるのは「今の顧客は迅速性を重視しているはずだ」といった、私たちの認識の側です。高次の制約条件そのものを毎回ブレさせることなく、それを具現化する「仮説の精度」だけを動的に高めていく。これこそが、IDOコンセプトの真の強靭さです。
また、AARは解釈を完全に一致させる装置ではない、という点も重要です。そもそも作動的に閉鎖された自己参照的システム(人間や組織の内部論理)同士の「完全同期」は理論的に不可能です。
AARの目的は、解釈のズレをゼロにすることではありません。組織が分裂や機能不全に陥らない範囲へ、解釈空間を「継続的に収束(調律)」させ続けることにあります。このサイクルが回っている組織では、不回避であるDriftすらも「仮説の精度を上げるための最高の燃料(データ)」へと変わるのです。
結論:手法の神格化を捨て、「再収束の機能」を実装せよ
私たちはここまで便宜上「AAR」という言葉を使ってきましたが、最後に重要なパラダイムシフトを提示します。
本稿は、AAR(あるいはダブルループ学習、リフレクション、OODAループ等)という特定のフレームワークそのものを神格化したいわけではありません。本質は手法の名称ではなく、「Driftした解釈空間を定期的に再収束させる仕組み(機能要件)」が、組織OSに組み込まれているかどうかです。その要件を満たすのであれば、名称は何であっても構いません。しかし、現時点で人類が獲得している最も洗練された実践知の一つが、AARという設計なのです。
過去の前例をトレースしていれば勝てた時代、組織は「正解主義OS」で十分に駆動しました。しかし、環境変化のスピードが前例の蓄積を遥かに上回り、AIが過去の正解を瞬時に出力する現代において、組織に求められているのは、未知の領域を切り拓く「探索能力」そのものです。
探索空間において、失敗とは悪ではありません。「Intent(制約条件)を実装した私たちの仮説が、現実とズレているよ」ということを教えてくれる、極めてクオリティの高いエラーシグナルに過ぎないのです。
日々のコミュニケーションに次の「3つのプラグイン」を差し込んでみてください。
【対話の冒頭】
「何を意図しているか」を1分で言語化する
指示の際、「これをやれ」ではなく、「〇〇という状態を作ることを意図している(制約条件の提示)」という枕詞をセットにする。
【トラブル発生時】
「なぜ起きたか」ではなく「想定との差分」を話す
問題が起きたとき、犯人を探すのではない。当初の想定(Intent)と何が違っていたのかを、COPという**「共通の観測面」**に差分として置いて、全員で一緒に眺める。
【評価の基準】
「正解のトレース」ではなく「仮説の更新」を称える
結果が失敗であっても、明確な企図(制約条件)を持って動き、精度の高い差分データを持ち帰って仮説を更新した行動を、システムの学習成果として承認する。
問題は、誰の能力不足でも、主体性のなさでもありません。IntentとCOPを媒介にして、偏流(Drift)する解釈空間を再収束し続ける「設計」が足りていなかっただけなのです。
不毛な「感想戦」や「査問会」を終わらせ、しなやかにズレを修正し続けられる組織OSへ。私たちの旅は、ここから始まります。
本稿の考察のまとめ
AARの真の位置づけ:
唯一の絶対解ではなく、漂流した解釈空間を機能不全が起きない範囲へ「継続的に収束」させるための代表的な機能解。
COPの核心:
単なる情報共有ではなく、ズレが「解釈の差」か「見ているものの差」かを判別し、Driftを測定可能にするための「共通観測面」。
三種の神器の役割分担:
Intent(制約条件)→ COP(共通観測面)→ Drift発生 → AAR(学習装置による再収束)→ 表現・運用仮説の更新、という動的組織OSの全貌。
組織は、自由を与えれば漂流する。
しかし、縛りすぎれば停止する。
では、人を縛らず、それでいて漂流もさせない制約条件は、どのように設計できるのか。
⸻
※「IDO」「Intent-Driven Orchestration」は、山添直智が提唱する独自の組織運営コンセプトです。
【全体ビュー数7000突破!(2026.August.3)】
🔳IDOコンセプト・ラボ専用メールアカウント開設しました!
フィードバック・ご意見等はこちらのメールアドレスまでご連絡下さい。
intentdriven2026@gmail.com
IDOコンセプトを実務に適用する上での疑問や、組織の現状に関するご意見をお寄せください。
「自組織で『IDOコンセプト』を導入しようとした際の障壁について」
「IDOの概念図の中で、特に分かりにくかった点」
「自身の組織における『確認文化』の具体的な事例」など
皆さんのチームでの事例等をご紹介頂けますと、IDOコンセプト深化の参考となります。
(組織の情報や個人情報等は公表しません。)
【あなたの組織が変わる15ステップ】
IDO宣言
◾️IDO(Intent-Driven Orchestration):Intent再定義で、組織の停滞は解消される
◾️Designできないリーダーは、なぜ「確認文化」を生むのか──Intent-Designが組織を変える
◾️IDOコンセプト導入ビフォー・アフター:組織のOSを書き換える「企図」の力(実装①)
Phase 0:違和感の発火
導 入:組織の不全を解く「ミッシングリンク」
第0回:“確認文化”が組織を止める
緊急投稿:「IDO」はすでに検索空間で再定義され始めている。
Phase 1:組織崩壊の認識
第1回:マネジメントの終焉
第2回:情報のパラドックス
第3回:任務指揮の正体
まとめ①:IDOとは何か
実装②:3時間かかる会議が、なぜ5分で決まるのか
補稿①:「共有」では組織は動かない。必要なのは“再同期”である。
補稿②:なぜ「強い組織」は説明できないのか
IDO診断:あなたのチームの“詰まり”を特定
Phase 2:新規OSの導入
第4回:日本型組織の呪縛
第5回:Intentは伝わらない──翻訳せよ。
補稿③:中間管理職を、「承認ルーター」から解放せよ。
5-1:なぜあなたの企図は機能しないのか
5-2:常識からの跳躍──問いは設定しても意味がない
補稿④:なぜ “Design” は二つ存在するのか。
5-3:コア提示──行動するな。まず定義せよ。
補稿⑤: 解釈の決断
5-4:Intent-Design プロセス前半──企図はどこで決まるのか(β版)
5-5:Intent-Design プロセス後半(β版)
第6回:IDOにおけるOODA
補稿⑥:AI時代の組織OS「IDO」前編
補稿⑦:AI時代の組織OS「IDO」後編
第7回:なぜ「企図(Intent)」は偏流するのか?
👉第8回:なぜAARは「査問会」になるのか?―漂流する解釈空間を「再収束」する組織OSの設計
補稿⑧:任務戦術のミッシングリンク
補稿⑨:学習し続けたからこそ負けた
補稿⑩:なぜ「権限委譲」では組織は動かないのか
まとめ②:なぜ、優秀なプレイヤーほどマネージャーになった途端に苦しむのか
Phase 3:IDO実装
第9回:情報は渡した瞬間に「意思決定」に変わる。
第10回:沈黙する組織が、最も速い。
実装③:なぜ優秀なチームほど動けなくなるのか
第11回:独断は、審判なき自由ではない。
第12回:任せるな。企図を渡せ。
第13回:なぜ最適解は、現場から連鎖するのか?
Phase 4:組織の進化
第14回:評価は「解放の装置」である。
第15回:なぜ、あなたのIDOは「起動」しないのか?
FINAL:
最終回:IDOが切り拓く組織の未来──「指揮」から「オーケストレーション」へ(8/23公開予定)
"From Control to Intent"
── 組織OSを「企図」で再起動する。
