AIが身近な道具になったことは、皆さんも日々体感されている通りだと思います。調査レポートは数時間で出てくるようになりましたし、資料の初稿も議事録の要約も、以前とは比べものにならない速さで手に入ります。
一方で、こんな感覚はないでしょうか。資料は速く揃うようになったのに、肝心の事業が前に進んでいる感じはあまりしない。会議の結論は相変わらず「引き続き検討」のままです。
AIを導入した新規事業チームと話していると、こういう話をよく聞くようになりました。
何度もヒアリングを重ねて出した結論は、速くなったのは資料を作る「作業」であって、事業を前に進める「判断」の機会は、AIを入れる前から増えていないのではないか？というものです。
本稿では、この見立てを思考実験で確かめたうえで、判断を任せるための前提となるポリシー（言語化された判断基準）の正体と、自前で作るための現実的なルートを整理します。
もし、人間が同じ速さで資料を作れたら（思考実験）
冒頭の実感を解きほぐすために、ひとつ思考実験をしてみます。AIのことは一旦忘れて、チームの誰もが、いまのAIと同じ速さで資料を作れるようになった世界を想像してみてください。調査レポートは数時間で揃い、事業計画書の初稿は一晩で出てきます。
この世界で、事業は前に進むのでしょうか。
...おそらく、進みません。資料が10倍の速さで揃っても、「この企画を続けるか、やめるか、方向を変えるか」を決める場が増えるわけではないからです。会議は今まで通りの頻度で開かれ、判断は今まで通りのペースでしか下りません。
ここから言えるのは、事業が進むかどうかは、もともと作業の速さにさほど依存していなかったということです。速く作れれば楽にはなりますが、それだけでは前に進みません。
では、もう一歩想像を進めます。作業だけでなく、判断まで速くなった世界ではどうでしょうか。検証の結果が出るたびに、続ける・やめる・曲げるの判断がその場で下り、すぐ次の検証が始まる。判断の頻度が上がっているのなら、この世界の事業は前に進んでいそうです。
2つの思考実験を並べると、冒頭の違和感の正体が見えてきます。AIを入れて変わったのは作業の速さだけで、判断の頻度が増えていないのです。
判断の頻度が、事業の進む速さを決める
なぜ判断の頻度がそれほど重要なのでしょうか。ハンドブックの事業開発の進め方で整理した通り、事業開発は検証の連続です。そして検証とは、続けるか、やめるか、方向を変えるかを判断できる材料を集める行為です。
材料が揃い、判断が下りて、初めて次の不確実性に取りかかれます。つまり事業開発は判断の連続であり、判断の機会がなければ、案件は活動を続けたまま止まっていきます。この状態が行き着く先は、ゾンビ化とは何かで扱っているゾンビ化です。
この整理を踏まえて、がむしゃらにAIを入れた組織で何が起きるかを見てみます。作業は確かに速くなり、判断待ちの材料が積み上がります。ですが判断の頻度が変わらなければ検証は完了せず、不確実性が減るスピードはAIを入れる前と変わりません。
もっと厄介なのは「検証した気」になることです。浅い検証を高速で大量に回せてしまうため、活動量は多いのに、判断の根拠は貯まりません。担当者が案件ごとに別々のAIに別々の前提で相談すれば、基準はむしろ散らばっていきます。速く動けるようになった分だけ、速く迷子になります。
「速くなった」という実感も、当てになりません。METRが2025年に公開したランダム化比較試験では、熟練のオープンソース開発者にAIを使わせたところ、タスク完了はむしろ19%遅くなりました。それでいて本人たちは「20%速くなった」と感じていました（METR, 2025）。開発タスクの話なので条件が変われば結果も変わりますが、自己申告の「速くなった気がする」を前進と数えてはいけないという教訓は、新規事業の探索にもそのまま当てはまると思います。
だから、事業を速く進めたいなら、判断の頻度を増やす必要があります。検証のたびに判断の場を持ち、何が確認できたら決められるのかを先に設計しておく。これはAIがあってもなくても成り立つ、進め方の話です。
そのうえで、もし判断のいくらかをAIに任せられるなら、探索は確実に速くなります。作業と判断の両方が速くなって、初めてループ全体の回転が上がるからです。では、判断を任せるには何が要るのでしょうか。前提から整理します。
ポリシー＝言語化された判断基準
チームには必ず判断基準があります。「この市場規模なら深掘りしない」「この顧客の声は重く見る」「あの領域は過去に撤退した経緯がある」。ただし多くは暗黙知で、会議の空気や過去のやり取りの中に散らばっています。
本稿では、この基準を言葉にして書き出したもの、つまり言語化された判断基準をポリシーと呼びます。
人間同士なら、暗黙知でもなんとか回ります。同じ部屋にいれば文脈は伝わるからです。
しかしAIは、書かれた基準しか参照できません。会議の空気は読めませんし、去年の撤退の経緯も知りません。基準が言葉になっていなければ、返ってくるのは「一般論として妥当な答え」までで、チーム固有の判断は再現されません。
ポリシーは「正解集」ではありません。書くのは、私たちのチームは何を重く見て、何を切り捨てるか、という選好です。だから完璧である必要はなく、暫定で構いません。使いながら直していくものです。
判断は二段に分かれる
ポリシーが書けると、何が変わるのでしょうか。任せられる判断の範囲が変わります。
判断はふたつの層に分けられると考えています。
ひとつは定型の判断です。基準が定まっていて、照らし合わせれば結論が出る判断を指します。「市場規模が基準未満のテーマは深掘りしない」「インタビューが判定ラインに達しなければ次の検証に進まない」。
この層は、基準さえ書かれていれば人が張り付く必要がありません。一次スクリーニングや検証結果の仕分けをAIに任せ、人は結果を検査する側に回れます。人が会議を待たずとも判断が下りていくので、判断の頻度はここで初めて上がりはじめます。
もうひとつはメタ判断です。基準そのものを更新する判断で、「市場規模の足切りラインは今のままでよいか」「今回の例外は基準に昇格させるべきか」がこれにあたります。ここには組織の合意と責任が伴います。どれだけ道具が進化しても、この層は人間に残ります。
この線引きが動くのは、基準を書けた組織だけです。書けない組織では、定型の判断もメタ判断も区別されないまま同じ人の頭の中に混ざっていて、AIに渡せる判断がひとつもありません。作業だけが速くなり、判断の頻度は元のまま変わらないのです。
開発チームが先に速くなっていた理由
この整理を裏づける実例が、すでに身近にあると考えています。ソフトウェア開発の現場です。
開発の領域では、AIエージェントに作業だけでなく判断のかなりの部分を任せる使い方が、いち早く日常になりました。なぜ開発だったのでしょうか。
開発チームには、AIが登場するはるか前から、判断基準を言語化してメンテナンスする文化があったから、という見方ができます。コーディング規約、コードレビューの観点、lintのルール、命名規則、デザインパターン、アーキテクチャの設計文書。「この書き方は許容されるか」「この変更は規約に沿っているか」といった判断の多くが、書かれた基準に照らせば結論が出る定型の判断になっていました。AIはその言語化物を参照して、人を待たずに動けます。
採用の領域でAI活用が進んでいるのも、同じ構図で説明できます。必須要件と歓迎要件が書かれ、面接で何をどう見るかが評価基準として言語化されている。書類の一次スクリーニングを任せようと思えば、任せるための基準が最初から存在していたわけです。
つまり、言語化された基準がある領域から順に、AIは判断を任される存在になっていきます。新規事業の判断基準は、ほとんどの組織でまだ暗黙知のままです。裏を返せば、ここを言葉にできた組織から、探索の判断を任せられるようになるということです。
自前で作る3つのルート
では、ポリシーはどう作ればよいのでしょうか。自前でも構築できます。共通の前提はひとつで、チャットで都度説明するのではなく、書かれた形で残すことです。都度の相談は便利ですが、基準がどこにも残らず、毎回コンテキストを渡し直すコストを払い続けることになります。
（a）会議の音声・ログから抽出する
議事録や録音、Slackのやり取りが残っていれば、そこには判断基準の原石が埋まっています。「なぜその案を見送ったか」の発言を拾い集め、基準として書き起こしていく方法です。
最も素材に忠実なルートですが、作業量が非常に大きいのが難点です。数ヶ月分のログを読み返し、判断の理由を特定し、一般化して文章にする。これ自体がひとつのプロジェクトになります。
抽出の作業はAIが手伝ってくれますが、どの発言がチームの基準で、どれがその場の思いつきかを選別する仕事は、メタ判断として人に残ります。さらに基準は事業の学習とともに変わるため、作ったあとも継続的なメンテナンスが必要です。
（b）コーディングエージェント＋gitで運用する
Claude Codeのようなコーディングエージェントにポリシーをテキストファイルとして持たせ、gitで版管理する方法です。いつ誰がどの基準を変えたかの履歴が残り、変更のたびにレビューを通せるため、基準を更新するメタ判断をそのまま運用フローに載せられるのが大きな利点です。
一方で、権限とセキュリティの担保が難しいルートでもあります。事業判断の基準は機密性の高い情報であり、誰がどこまで読み書きできるかの設計が要ります。
また、この運用はチームのgit理解が前提になります。事業開発チームの全員がブランチとプルリクエストを扱えるケースは、まだ多くありません。このルートの実際の使い方と効く条件は、新規事業開発でのClaude Codeの使い方で深掘りしています。
（c）ドキュメントツールで運用する
Notionなどのドキュメント管理の中にポリシーのページを作り、チームで編集していく方法です。参加のハードルが最も低く、始めやすいルートです。
ただし課題は（b）と重なります。基準の更新を誰がいつ承認するのか、古くなった記述をどう検知するのか。ページは作れても、「生きた基準」として回し続けるワークフローを組み切れるかが壁になります。更新が止まったポリシーのページは、参照されない社内Wikiと同じ道をたどります。
明文化から始める。完成度より更新
3つのルートに共通するのは、明文化そのものに価値があるという点です。
ポリシーさえ書ければ、使い先は選びません。連携の仕組みは広がり続けており、言語化された基準はどの道具からも参照できる資産になります。特定のツールに縛られる心配は要りません。
仮に道具を一切使わなくても、明文化は効きます。新しいメンバーの立ち上がりが変わり、会議で「そもそも何を基準に議論しているのか」を確認し直す時間が減ります。判断がぶれたときに立ち返る場所もできるでしょう。
基準が個人の頭の中に閉じているのは、誰かの能力の問題ではなく仕組みの問題です。だから、仕組みで解けます。
ポリシーの育成は、ノウハウの集約・学習資産の構築と並ぶ構造課題のひとつです。3つを体制づくりの文脈でまとめた資料はなぜテーマ選びより、体制なのかに整理しています。
だから、道具選びは後回しで構いません。まず、チームの判断基準をひとつ言葉にしてみてください。「私たちはなぜあの案を見送ったのか」を1枚に書き出すところから、ポリシーづくりは始まります。
完成度を上げてから使い始める必要はありません。暫定の1枚を今日から判断のたびに参照し、合わなければその場で直していけば十分です。
基準を書けた組織だけが、定型の判断まで任せられるようになります。作業に続いて判断まで速くなったとき、初めて探索のループ全体が回り出します。書き始めた1枚は、あなたの判断をチームの基準に変える最初の資産です。