「#203」 AIエージェント時代、あなたの「CQ」が組織の生存戦略になる
初めに
前回、「誰でも使えるAIエージェント時代の、本当の差別化」というタイトルで「良いAIを使っているか」ではなく、「AIエージェントを使いこなせる設計書を、貴方の会社は持っているか」という問いを提起しました。
答えを出す仕事の大半は、もうAIの担当だ。
長い間、私たちの仕事の多くは「正解を探す」ことだった。要件を整理し、既知のパターンに当てはめ、最適な手順を組み立てる。そこに価値があった。
だが生成AIとエージェントが台頭した今、その前提が崩れている。データ処理も、定型的なコード生成も、最適化計算も、AIの方が速く正確にこなす。人間に残された仕事は何か。
それは「何を解くべきか」を決めることだと思う。
「良い答え」には「良い問い」がある。
AI時代になぜCQが重要なのか
CQ（Curiosity Quotient／好奇心指数）という言葉を最近よく見かける。Forbes JAPANの記事でも、変化の激しい技術環境において学び続け、未知の領域に疑問を持つ力が、人間最大の武器になると語られていた。
私はこれを、現場感覚としてAIを使うようになって強く実感している。
AIエージェントにタスクを渡す前に、必ず一つの作業が発生する。「そもそも何を目標とするか」「どんな制約条件を設定するか」を定義する作業だ。この定義が曖昧だと、AIはどれだけ優秀でも、見当違いの成果物を高速に量産するだけになる。
問いを立てる力こそが、AIの出力の質を決める。IQでもスキルでもなく、CQ——好奇心を起点に本質的な問いにたどり着く力が、これからの実務能力の中心に来ると考えている。
1. 業務・開発現場での構造設計への落とし込み方
CQは抽象論では終わらせられない。私が実際の現場でやっているのは、次のような手順だ。
① 「なぜ」を3回掘る
要望をそのまま要件にしない。「なぜこの機能が必要か」「なぜ今のやり方では駄目か」「なぜこの制約があるか」を3段階掘り下げる。掘るたびに、表面的な要望の下にある本質的な課題が見えてくる。この本質的課題こそが、AIエージェントに渡すべき「問い」になる。
② 業務の地図を先に描く
いきなりAIにプロンプトを投げない。誰が、何を、どんな順番で、何を判断材料にして動いているか——業務の骨組みを先に可視化する。この地図がないままAIを導入すると、PoCで止まる。個別の作業は自動化できても、業務全体の構造が見えていないので、次のステップに進めない。
実はこの工程、オントロジー工学の手順とほぼ重なる。オントロジーを設計するときも、モデルを組む前に「このオントロジーは何を答えられるべきか」というコンピテンシー・クエスチョンをまず定義する。骨組みは、良い問いなしには描けない——CQとオントロジーは、同じ根から生えている。
③ 制約条件を仕様書ではなく問いとして書く
「在庫数を確認して発注する」ではなく、「欠品リスクと過剰在庫コストのどちらを優先するべきか」という問いの形で制約を書く。この違いが、AIエージェントが柔軟に判断できる余地を生む。仕様書は正解を固定するが、問いは探索の余地を残す。
2. CQを個人・組織で高める具体的方法
CQは才能ではなく、習慣だと私は考えている。
個人レベル
毎日ひとつ、「当たり前」を疑うメモを残す。業務の中で違和感を覚えた瞬間をそのまま流さず、一行でいいから書き留める。
専門外の領域の記事を意識的に読む。私自身、農業の現場で感じる勘所が、IT設計の発想に何度も転用できた。異分野の往復がCQの燃料になる。
「答え」ではなく「良い問い」を人に話す。良い問いは会話を続けさせる。答えは会話を止める。
組織レベル
会議の冒頭を「今日決めること」ではなく「今日問うべきこと」から始める。
失敗した施策を「なぜ失敗したか」ではなく「そもそも何を問うべきだったか」で振り返る。
評価制度に、正解を出した人だけでなく、良い問いを立てた人を評価する項目を入れる。
CQは個人の資質である以上に、それを歓迎する場があるかどうかで決まる。問いを立てた人が損をする組織では、CQは育たない。
3. AIエージェントを活用したワークフローの組み方
最後に、これを実務のワークフローに落とし込む方法。
ステップ1：人間が「問い」を定義するフェーズを明示的に切り出す
AIエージェントに丸投げする前に、「このタスクの目的」「判断基準」「除外条件」を人間が言語化するフェーズを、ワークフローの独立した工程として置く。ここを飛ばすと、後工程がどれだけ自動化されていても崩れる。
ステップ2：エージェントには「実行」と「一次判断」を任せ、「再定義」は人間に戻す
エージェントが出した結果に対して、「この判断基準のままでいいのか」を問い直すタイミングを、ワークフローに組み込む。私が構築してきた複数エージェント構成（PM役・開発役・分析役などを役割ごとに分けた構成)でも、各エージェントの出力を突き合わせた後、必ず人間が「前提が正しかったか」を確認する工程を挟んでいる。
ステップ3：問いを検証し、ログを資産化する
どんな問いを立て、どう再定義し、結果がどう変わったか。このプロセスをログとして残すだけでは足りない。「その問いは、実際に良い問いだったか」を事後に振り返る検証の工程を必ず挟む。オントロジー工学でコンピテンシー・クエスチョンをSPARQLで検証するように、立てた問いも「それによって何が変わったか」で答え合わせをする。検証を経た問いだけが、次に似た課題が来たときの精度を上げる。個々のプロンプトよりも、この「問いと検証の往復」こそが組織の知的資産になる。
ステップ4：複数エージェントが動く前提で、監視の仕組みを先に用意する
一つのエージェントを手元で動かしているうちは、人間の目が監視の代わりになる。だが実務でPM役・開発役・分析役といった複数エージェントを同時並行で動かし始めると、そうはいかない。どのエージェントが、いつ、何を判断し、どこで止まったか。人間の目視だけでは追いきれなくなる。ここで必要なのが、エージェントの稼働状況・判断ログ・異常終了を一元的に可視化する監視ソフトウェアだ。
ちょうどこの用途にぴったりのツールを、師匠の小野氏が作っている。PaneDeckというElectron製のターミナルアプリで、複数のコーディングエージェントのセッションをグリッド状に並べて表示し、それぞれが「実行中」「入力待ち」「待機」「終了」のどの状態かをバッジで一目でわかるようにし、必要なら複数セッションへ同時に指示を送れる。何十タブも行き来して「どれが止まっているか」を探す作業から解放される、という発想そのものが、この記事で言いたかった「複数エージェント運用には監視が要る」を体現している。
問いを検証する工程(ステップ3)と、エージェント群の挙動そのものを監視する工程は、似ているようで別物だと私は考えている。前者は「その問いは正しかったか」を問い、後者は「そのエージェントは今どう動いているか」を問う。両方を仕組みとして持って初めて、複数エージェント構成は安心して任せられる。
CQの罠——問いすぎることのリスク
ここまでCQを推してきたが、一つだけ釘を刺しておきたい。
問いを立てることと、問い続けて動けなくなることは、紙一重だ。「本当にこの前提でいいのか」を掘り下げすぎると、いつまでも実行に移れない。現場では、これを何度も見てきた。骨組みを固めるための問いのはずが、いつの間にか完璧な問いを探す作業そのものが目的化してしまう。
だからCQには、もう一つの力が対になっている必要がある。「このくらい掘れば十分」と見切りをつけ、不完全な前提のまま一歩動かす力だ。オントロジー設計でも、コンピテンシー・クエスチョンを永遠に練り上げるのではなく、ある時点で仮のモデルを組み、実データで検証しながら精度を上げていく。問いを立てるフェーズと、仮説のまま動かすフェーズを、意識的に切り替える。
良い問いは、答えを一つに絞り込むためではなく、次の一歩を踏み出せる状態を作るために立てる。そこを見失うと、CQは武器ではなく、足かせになる。
おわりに
AIが答えを出す時代に、人間の価値は「良い問いを立てる力」「AIの違和感を拾える力」に収斂していくと考えている。
CQは精神論ではない。業務設計の手順に組み込み、個人と組織の習慣として仕込み、エージェントワークフローの明示的な工程として位置づけることで、初めて実務能力になる。
PoCの記事で何回も書いてきた「正解探しでなく、正解を育てる力」。
「良い答え」には「良い問い」がある。答えを急ぐ前に、まず問いを疑う。それが、エージェント時代を生き抜くための、いちばん実践的な構えだと最近エージェントを多用していて強く思う毎日です。
参考
この記事で触れた「コンピテンシー・クエスチョン」の話は、私の師匠である小野氏が、連載「AIエージェント時代のオントロジー」の中で、LLMとオントロジーを組み立てる一部始終を90分のハンズオンとして公開されている。
LLMと90分でオントロジーを作る ―修理報告書3通からナレッジグラフまで｜ガマ仙人
まず問いを決め、その問いに答えられるかをLLMに検証させ、答えられなければ設計を差し戻す。この記事で私が言葉にした「問いを立てて、検証し、資産化する」というループが、小野さんの記事では実際に手を動かせる形で、コードと数字とともに示されている。CQを理屈で終わらせたくない方は、ぜひ手元で90分、試してみてほしい。
