AI活用の差は、組織の運用設計で決まる

AIを導入して、メンバーもそれぞれ使い始めた。それなのに、チームとしての成果はあまり変わっていない……そんな状態になっていないでしょうか。

しかも困ったことに、症状は「使われていない」ではなく「使われすぎてバラバラ」という形で出てきます。似たような指示書やSkillがあちこちで別々に作られている。同じ業務を頼んでいるはずなのに、成果物の精度が人によって違う。アウトプットの形式に統一感がなく、後から見返すと誰が何を作ったのか分からない。

私自身、個人の作業環境で同じことを経験しました。プロジェクトが十六個に増えた時点で、指示書が二十個、Skillが八個に散らばっていて、どれが生きているのかを自分でも把握できなくなっていたのです。一人でこうなるのですから、複数人の組織で起きないほうが不思議です。

この構造をうまく言い表している記事があります。生成AIの導入は、派手には失敗しない。静かに崩れるのは「組織が意図した使い方」のほうだ、というものです（tk_notes「生成AIを組織に定着させるための、渡し方・受け方・測り方・育て方の設計」）。使う人はちゃんと残る。ただ、それぞれが各自のやり方に分岐していき、組織として用意した公式の経路だけが静かに素通りされていく。だから失敗として認識されないまま進行します。

この記事では、プロンプトの書き方やツールの選定には触れません。そこはすでに多くの情報があります。扱うのは、組織としてAIをどう運用するかの設計です。結論を先に言えば、AI活用の差を生んでいるのはモデルの性能でも個人のスキルでもなく、運用設計そのものだと考えています。

個人で使うAIと組織で使うAIは、別物である

まず押さえたいのは、個人利用の延長線上に組織利用はない、という点です。同じツールを使っていても、要求される性質がまったく違います。

観点	個人で使うAI	組織で使うAI
判断基準	自分が納得すればよい	他人が検証できる必要がある
失敗のコスト	やり直せば済む	誰かの判断材料になり、下流に波及する
再利用	覚えていれば十分	明文化されていなければ再利用できない
形式	揃っていなくてよい	揃っていないと比較・集約ができない
教育・引き継ぎ	不要	新しい人が同じ品質を出せる必要がある
機密	自分の裁量	線引きを組織として決める必要がある

この表で私が一番重いと思っているのは、五つめの「教育・引き継ぎ」です。個人利用では、うまくいったやり方は自分の頭の中に残しておけば足ります。ところが組織では、頭の中に残した時点でそれは組織の資産になりません。担当者が異動した瞬間に、その業務のAI活用はゼロに戻ります。

この認識を裏づける調査があります。消費者と企業担当者あわせて1,010名を対象にした調査では、AIを導入した企業の75%が、現場の課題を解決できていないという結果が出ています。そして原因として指摘されているのは、ツールの不足ではなく業務プロセスへの組み込み不足でした。

もう一つ、総務省の情報通信白書の数字も見ておきます。企業のAI利用率は55.2%から86.4%へと急激に伸びました。ただ、その効果は業務効率化に大きく偏っていて、製品・サービスの質の向上を挙げた割合は他国のおよそ半分にとどまっています。さらに象徴的なのが、社内データベースの構築に取り組んでいる企業が日本では24.5%と、これも他国の半分程度だという点です。

二つの調査は同じことを別の角度から言っています。つまり、多くの企業は「AIを使い始めた」段階には到達したものの、「AIに渡せる情報と手順を組織として整えた」段階には進めていない、ということです。導入はイベントですが、定着は状態です。 イベントは日付で終わりますが、状態は設計しなければ維持できません。

運用は、言語化しなければ渡せない

では、何から設計すればよいのでしょうか。私は最初にやるべきなのは運用の言語化だと考えています。

理由はシンプルで、言語化されていない運用は、AIに委譲できないからです。 人間の部下であれば、隣で見て覚える、空気を読む、前任者のやり方を真似る、といった経路で暗黙知が伝わります。AIにはその経路がありません。渡せるのは、文字にしたものだけです。

言語化には段階があります。私は三つのレベルで捉えています。

暗黙知 — 担当者の頭の中にあり、聞けば答えられるが、書かれていない状態
手順書 — 人間が読んで再現できる形に書かれた状態
実行可能な定義 — AIがそのまま参照して動ける粒度まで具体化された状態

多くの組織は一と二の間で止まっています。そして厄介なのは、二から三への距離が、想像よりずっと長いことです。手順書には「適宜判断する」「必要に応じて確認する」といった表現が普通に登場しますが、これはAIに渡した瞬間に破綻します。何をもって「必要」とするのかが書かれていないからです。

「なぜ」は、後から書けない

言語化で見落とされがちなのが、判断の理由です。手順は書けても、なぜそうするのかは書かれないまま残ります。

ある記事で、これを的確に指摘していました。既存の仕組みを直すときの「なぜ」は、時間がなくて書けず、結局コミットメッセージに一行残るだけになる。そして後からAIに書かせると、空疎な文章にしかならない。理由は明快で、「なぜ」は変更の前に頭の中にあるものだからです。だから、先に書くワークフローに変えるべきだ、と。

これは組織の運用にもそのまま当てはまります。手順を決めた背景、あえて非効率な確認を挟んでいる理由、過去に事故が起きたので禁止していること――こうした情報は、決めた瞬間にしか書けません。後から復元しようとすると、誰も理由を覚えていない、という事態になります。

ただし、書けば守られるわけではない

もう一つ、言語化について正直に書いておくべきことがあります。ルールを書いただけでは守られません。

印象的な実測がありました。AIに文体のルールを渡したうえで投稿を生成させたところ、200件のうち196件が同じ一文で終わっていたというものです。ルールは渡してある。それでも、書いてあるだけでは制御しきれなかったわけです。

これは言語化が無駄だという話ではありません。言語化は必要条件だが、十分条件ではないということです。書いたうえで、それが守られているかを確認する仕組み――形式のチェック、成果物のレビュー、逸脱の検出――までを含めて、はじめて運用になります。

なお、社内のFAQやヘルプデスク業務をAI化した事例でも、似た結論が出ていました。独自システムの開発よりも、運用設計と文書整備を優先すべきだというものです。投資すべきはシステムではなく、情報の整理のほうだ、と。先ほどの白書の数字――社内データベース構築が24.5%にとどまるという話――と、きれいに符合します。道具を先に買っても、渡すものが整理されていなければ動きようがない、ということでしょう。

フロー化とは、判断を残す場所を決めること

言語化の次はフロー化です。ただ、ここで誤解しやすいのは、フロー化を「すべてを自動化すること」だと捉えてしまうことです。

私はむしろ逆だと思っています。フロー化とは、どこを固定し、どこを人間の判断として残すかを決める作業です。

人はループの中から、外へ移る

この分野では最近、ループエンジニアリングという言葉が使われるようになりました。AIが自動的に働き続けるように設計することを指します。ここで語られている変化が示唆的で、人間の関与が “Human in the Loop”（ループの中で都度判断する） から “Human on the Loop”（ループの外から監督する） へ移りつつある、というものです。

ただし、実践者の話を聞くと、慎重な前提が二つ付いています。

一つは、最初からループ化してはいけないということ。まず各ステップを個別に効率化し、手順書を整備する。それが済んでからループにする。順序を逆にすると失敗する、と実践者は述べています。

もう一つは、停止条件を必ず決めること。成功条件と打ち切り条件を設定しないと、無駄にループが回り続けます。これは費用に直結します。

私も「無限ループ・無制限リトライは禁止、リトライは最大三回まで」というルールを自分の指示書に明記しています。個人で費用を負担する以上、暴走は許容できないからです。

自律と統制を、同居させる

企業向けのAIエージェント設計についての解説で、論点の移り変わりをうまく整理していたものがあります。かつては「自律をどこまで許すか」が論点だった。それが今は「自律と統制をどう同居させるか」に移っている、と。

許可か禁止かの二択で考えている限り、議論は前に進みません。同居させるという発想に切り替えると、「どの範囲は自律に任せ、どの一点だけは人が握るか」という設計の話になります。

一つに絞らせない

その「一点」をどこに置くか。医療現場でのAI活用の話が、明快な原則を示していました。AIに一つを絞らせないというものです。候補を出すところまではAIの仕事、そこから確定させるのは人の仕事、と役割を切る。「候補を十個出してください」までは有用だが、そこから一つに決めさせた瞬間に危険になる、ということです。

これは医療に限りません。採用候補の絞り込み、施策の優先順位づけ、原因の特定――「最終的に一つに決める」性質の業務は、どれも同じ構造を持っています。AIに絞らせると、絞った理由が検証されないまま下流に流れてしまいます。

関連して、もう一つ大事な観点があります。「分かりません」と言えるAIこそ安全だという考え方です。回答率を上げることを目標にすると、AIは知らないことにも答えようとします。運用設計としては、答えない選択肢を明示的に許可しておく必要があります。これは精度の問題ではなく、設計の問題です。

外枠を設計する――ハーネスという捉え方

言語化して、フロー化した。それをどこに置くか、という話になります。ここが運用設計の骨格です。

この領域には、ハーネスエンジニアリングという呼び名が付き始めています。AIエージェントの周辺インフラ――コンテキスト、ツール連携、記憶、ガードレール、監視――の全体設計を「ハーネス（馬具）」と呼び、それを整える実践知を指す言葉です。モデルそのものを作るのは開発者の仕事ですが、ハーネスを整えるのは使う側の仕事であり、そこが主戦場になる、という整理です。

使う側にとって、ハーネスの中身は大きく三つに分かれます。

一つめはフォルダです。 フォルダは単なる整理棚ではなく、AIに読ませる単位として機能します。どこまでを一つの作業範囲とみなすかを、フォルダの区切りが決めてしまう。だからこそ、人が見て整理されている構成と、AIに読ませて有効な構成は、必ずしも一致しません。

二つめは指示書です。 判断基準や制約を書き、階層ごとに適用範囲を分けます。この仕組みについては、以前基礎編と応用編で詳しく整理しました。

なお、指示を書ける場所は実際にはもっと細かく分かれます。ある記事では、Claude Codeの挙動を制御する手段を七つの指示面――指示書、ルール、Skills、サブエージェント、Hooks、出力スタイル、システムプロンプト追加――に整理し、「読み込まれるタイミング」「圧縮後に残るか」「権威の強さ」「コンテキストの消費量」の四軸で使い分けるべきだとしていました。組織で運用するなら、どの指示をどの面に置くかを決めておくこと自体がルールになります。

三つめはエージェントです。 役割を切り出して、専門の担当を作る考え方です。人間の組織で職掌を分けるのと同じ発想ですが、切り出し方には固有の勘所があります。

セキュリティは、二つに分けて考える

外枠の設計には、当然セキュリティも含まれます。ここは深入りしませんが、二軸に分けると議論が具体的になるという整理が有用でした。

データの軸 — 会社の情報を、そのAIに渡してよいか
行為の軸 — AIが勝手にメールを送る、ファイルを消すといった動作をどこまで許すか

この二つは混同されがちですが、対策はまったく違います。データの線引きは契約形態や利用規約の確認が中心になり、行為の制限は権限設定や承認フローの設計になります。「AIは危ないから禁止」と「便利だから全部使う」の間で止まっている組織は、たいていこの二軸を分けていません。

IT部門が線を引いてくれない小さなチームでは、この二軸を自分たちで決めるところから始めることになります。

考察――「精度を上げる」ではなく「間違えても壊れない」

ここまでを整理すると、組織のAI運用は三つの層で捉えられます。

入力の層 — AIに何を渡すか（情報の整理、社内データの整備）
出力の層 — 何を受け取り、どう検証するか（形式の統一、確定は人が行う）
外枠の層 — どこに置き、誰の役割にするか（フォルダ・指示書・エージェント）

そして最も議論されにくいのが、三つめの外枠の層です。プロンプトの工夫は入力の層、ファクトチェックは出力の層の話であり、どちらも比較的よく語られます。ところが外枠は、目に見える成果物にならないため後回しにされがちです。

私は、組織で差がつくのはこの外枠の層だと考えています。理由は、入力と出力の質は外枠に規定されるからです。フォルダが整理されていなければ渡す情報は選べませんし、役割が定義されていなければ出力の検証者も決まりません。

そしてもう一つ、運用設計の目標設定について。**目指すべきは「精度を上げること」ではなく「間違えても壊れないこと」**だと思っています。

これについて、腑に落ちる表現に出会いました。個人開発で三ヶ月かけて品質ゲートを設計した記録の中の一文です。AIはコードを速く書くが、もっともらしい間違いも同じ速度で書く。 だから作るべきなのはAIを信用する仕組みではなく、採用の責任を人に残すための仕組みだった、というものです（tk_notes「AIエージェントにコードを書かせて、人が品質を守る」）。

これは開発に限らない話だと思います。AIの出力が常に正しいことを前提にした運用は、一度の失敗で信頼ごと崩れます。一方、候補出しまでをAIに任せ、確定を人が行い、成果物の形式が揃っていて後から検証できるなら、間違いは途中で止まります。同じ精度のAIを使っていても、壊れる組織と壊れない組織に分かれるのは、この設計の差です。

最後に、測り方にも触れておきます。AIツールを導入したものの「誰がどれだけ使っているか」が分からないブラックボックス状態になり、それを可視化する仕組みを自作した事例がありました。定着しているかどうかは、意識せずに測ろうとすると見えません。 冒頭で触れた「静かに崩れる」という表現が効いてくるのはここで、崩れていることに気づく手段を持っていなければ、崩れていないのと区別がつかないのです。

冒頭の三つの症状――似たSkillの乱立、精度のばらつき、形式の不統一――も、突き詰めればすべて外枠の設計不足から来ています。裏を返せば、外枠さえ決めれば、個々のメンバーが特別なプロンプト技術を持たなくても、組織としての出力は揃うということです。

おわりに

AI活用の差は、モデルの性能差でも個人のスキル差でもなく、運用設計の差である――これがこの記事の結論です。そして運用設計は、言語化・フロー化・外枠の設計という三段階で進められます。

とはいえ、ここまでは考え方の話です。「では自分の環境でフォルダをどう切るのか」「エージェントに何を任せ、何を任せないのか」という具体になると、また別の整理が必要になります。

次回は実践編として、業務の種類ごとのフォルダ構成パターン、エージェントへの役割の振り方と定義ファイルに書くべき内容、モデルの使い分け、そして運用を続けると必ず起きる「フォルダの肥大化」への対処までを、実際に自分の環境を測った数字とあわせて扱う予定です。