AIに繰り返し使わせる作業手順をまとめたSkillが増えると、どの前提を次の工程に渡したのか関係性の管理が難しくなります。市場算定のように正解を直接確認できない業務では、最終的な計算値が一致したという事実だけでは前提が正しいか判断できません。
個別の分析を担う子Skillには、入力と出力に加えて合格条件を持たせます。全体の実行順を管理する親Skillが、その結果と未確認事項を次の工程へ渡す設計です。
この設計は分析の正解を自動で保証するものではありません。各工程の記録を残すことで、人が不確実な仮定や誤りを発見し、最終的な利用判断を下すための道筋を整理します。
Skillが増えたら最終値より途中の根拠を追う
環境分析、複数の将来像の検討、市場規模の算定を別々のSkillへ任せると、同じ地域や時点を扱っているか見えにくくなります。出力だけを次のSkillへ渡すと、途中で置いた仮定を後から確かめられない場合があります。
市場規模の算定では、異なるアプローチで計算した複数の結果が近い値になることがあります。しかし、複数の算定Skillが同じ誤った顧客母数や単価を前提としていれば、誤った数値のまま結果が一致してしまいます。そのため、最終的な算定結果の数値が揃ったという事実だけでは、その分析全体が正しいという証明にはなりません。
市場算定のように直接正解を確認できない分析業務では、最終値だけでなく途中の計算過程の評価が重要になります。イギリス政府の分析品質ガイドラインであるAQuA Bookでは、仕様通りに正しく処理されたかの確認と、目的に適しているかの検証を区別しています。単に同じ数値が出力されたことをもって、分析の前提が正しいとは保証していません。
分析の途中でどのような推論が行われたかを知るには、算定式、前提条件、シナリオ、中間成果物を個別に確かめる必要があります。Anthropicのエージェント評価解説でも、AIの完了発言と実際の最終状態を区別し、根拠や資料の質を含めて評価することが推奨されています。実行記録を残すことで、どの入力から食い違いが入ったか調べやすくなります。
子Skillは単独で合否を確かめられる単位に分ける
政治・経済・社会・技術から外部環境を見るPEST分析も、四つのファイルへ必ず分ける必要はありません。細かく分けるたびに分析の前提が欠落したり、同じ資料を繰り返し読んだりするなら統合した方がよいでしょう。独立した入力と保存できる出力があり、合格条件と修正の差戻し先を設定できる単位を分割の境界とします。
例えば、外部環境の変化を原資料付きで整理するSkill、その変化から複数の将来像を組み立てるSkill、前提を数式へ入れる市場算定Skillへ分けます。この分割基準は独自の設計提案であり、製品の公式な必須規則ではありません。それぞれが単独で合否を確かめられる成果物を出すことが重要です。
分割した子Skillを正しく動かすには、前提条件を明確に渡す必要があります。入力には対象地域や基準年、予測年や通貨、対象顧客や資料ID、未解決事項を含めます。出力には分析の主張だけでなく、根拠となる資料IDや、観測された事実と未検証の仮定の区別を残すように設計します。
各工程の合格条件は、単に指定された名前のファイルが存在することではありません。原資料が分析の主張を正しく支えているか、指定した地域・期間・単位の前提を維持したかを確認します。さらに、次の工程を担うSkillに必要な不明点や条件が欠落していないかを読み取ることも合格条件に含めます。
Anthropicのワークフロー解説では、経路を定めるワークフローと動的なエージェントを区別し、複数の処理に分けて確認を挟む構成を紹介しています。全体の進行を担う親Skillは、各子Skillの名前と保存場所、入出力や依存関係、評価結果と修正先を管理します。
親Skillが実行順序を管理するのは、前後の工程の依存関係を満たすために必要だからです。ただし、道具を同じ順番で使うこと自体を一般的な成功条件にしてはいけません。有効な別の処理経路を失敗扱いする可能性があるため、独立した成果物の中身で成否を評価する仕組みが求められます。
PESTから将来像と市場算定へ前提を引き継ぐ
PEST分析から複数の将来像を検討するフォーサイトへ渡すとき、単に規制があるというラベルだけでは不十分です。Horizon Scanning Templateのように、変化の兆候、時間軸、関連する根拠を記録します。誰に何を要求する規制なのか、施行時点や対象地域、原文出典、不確実性といった前提を維持して引き継ぎます。
2027年に倉庫の管理者が勤務シフトを組む架空のサービスを例に考えます。分析担当者の判断は、東地域で実証実験に進むかどうかです。「記録保存の負担が購入需要につながる」という仮説を置き、購入意向と保存機能の証拠を集めます。既存の方法で十分だと顧客が答えるなら、この需要仮説を見直します。
英国政府のFutures Toolkitでは、シナリオを予測値ではなく複数の将来を検討する手法として扱います。架空の規制メモが記録保存を要求していても、特定ソフトの購入を要求するとは限りません。フォーサイト側は、どの根拠からどの因果関係を仮定したかを付け加えます。
将来像から市場算定へ渡す情報も、「普及するはず」という結論だけではありません。対象顧客、利用を妨げる条件、購入に必要な機能、採用率の根拠を渡します。仮定が未検証である状態もそのまま引き継ぎます。将来像のシナリオで想定した条件を観測済みの事実として扱ったり、資料にない確率をAIがもっともらしい確定値に変換したりしないように注意します。
算定工程では対象範囲と計算式、仮定を別々に確かめます。Waterloo大学の市場規模分析ガイドが示すように、市場定義を維持する必要があります。対象市場全体であるTAM、提供可能な範囲のSAM、獲得見込のSOMを明確にします。今回の架空例のTAMは対象地域内であり、世界市場全体ではありません。
算定で用いる数値の矛盾も、そのまま記録として引き継ぎます。架空例では、月額12,000円の料金表と年額120,000円の営業メモが食い違っています。さらに全国10,000件と対象地域2,400件の倉庫数が混在しています。
聞き取りの相手は、協力を得やすかった三人の管理者です。この選び方を便宜抽出と呼び、地域全体の意見を代表するとは限りません。試算では対象地域の全倉庫の25%が利用可能で、そのうち10%を獲得すると仮定します。この二つの割合に裏付けはなく、確定値として扱いません。
計算式による算術と、前提となる割合や単価の妥当性は、それぞれ異なる確認項目です。掛け算が合っていても、対象外の倉庫を含めていれば市場規模を過大に見積もります。原資料、観測された事実、未検証の仮定、不明点を分けて渡すことで、人がどの前提を調べ直すか判断できます。
Codexの親Skillに実行順と確認先を持たせる
実行前に、検査プログラムを動かすPython3、変更履歴を管理するGit、ファイルを読み書きするAIツールのCodexを用意します。
ターミナルで使うCodex CLIをnpm install -g @openai/codexで導入する場合は、Node.jsとnpmも必要です。検証用ZIPを展開すると、input.jsonとcheck.py、親と三つの子Skillの定義が得られます。
展開したanalysis-skills-exampleフォルダをターミナルで開きます。以下は、そのフォルダが現在の作業場所になっている状態で実行するコマンドです。pwdの末尾がanalysis-skills-exampleであることを確かめてから進めてください。
pwd
git init
codex --version
codex login status
未ログインの場合は本人がcodex loginを実行します。ログイン状態の表示だけでは利用枠の残量までは分からないため、開始後に/statusでも確認します。
この例は本人のChatGPTアカウントでログインし、その利用枠で実行します。APIキーを使う場合のPlatform側の従量課金とは別の経路です。認証仕様に基づく利用枠や管理者権限は、組織の契約内容で個別に確認します。
準備ができたらcodexで対話を開始します。mode=intermediateは、各工程の直後にAIレビューを挟む指定です。以下をCodexの入力欄へ貼り付けてください。Skillの公式仕様に従い、親の定義は.agents/skills/analysis-parent/SKILL.mdに置いてあります。
$analysis-parentを使い、input.jsonを入力としてmode=intermediateで実行してください。出力先は新規フォルダruns/my-trialとしてください。
親の指示に従い、同じCodexエージェントが順番に子Skillを読んで処理を進めます。親Skillは入力であるinput.jsonを読み、PEST、フォーサイト、市場算定の順に実行します。入力から出力、レビュー、次工程への引き継ぎという親子関係が、記録から読者に追えるようにファイルを出力します。
本実験は既存のCodex内で定義ファイルを明示して実行した例です。上記のCLIでの自動探索や、codex execで推論を実行する経路までは試していません。定義を読まない場合は、親Skillのファイルパスを直接指定します。
Skill内のStopは、終了時の検査コマンドを記した宣言です。この実験では宣言による自動実行を検証していないため、次の検査は手動で実行します。
検証用ZIPに含まれるcheck.pyを使い、シェルでpython3 check.py --run runs/my-trialを実行します。errors内の各配列が空なら、構造や算術等の検査を通過しています。
その後、人がinput.jsonと次の出力ファイルを開き、主張が資料と合うか確認します。保存先はいずれもruns/my-trial内です。
pest.json：外部環境の主張と出典foresight.json：将来像と因果関係の仮定market.json：市場範囲、計算式、未確認の前提review.json：AIが指摘した箇所と修正内容
記録にreviewed_by_aiとあっても、人が確認済みであることを意味しません。
同じ架空課題で評価のタイミングを比べる
架空の2027年倉庫シフトサービスを題材に、同じ資料とSkillを用いた代表試行の結果を比較します。各工程の直後に確認する中間評価と、三工程の初稿保存後にまとめて確認する最終一括の二条件を試しました。それぞれ独立した新規Codexエージェントで一回ずつ実行しました。レビューもAIが行った各条件一回の例示であり、精度率や優劣を推定するものではありません。
両条件とも修正前の初稿を保存し、AIによる修正は各工程一回までとしました。入力資料とSkillの定義を揃えたうえで、レビューするタイミングを変えています。料金や倉庫数の矛盾を解消する新資料は与えていません。
実行の結果、両条件とも初稿時点で料金と母数の不一致を保持したまま算定を進めました。対象地域2,400倉庫に25%と10%を掛けると、仮定上の獲得数は60倉庫です。
両条件のSOMは、月額を12か月分にした144,000円×60の864万円と、年額メモの120,000円×60の720万円を併記しました。中間評価だけが誤りを発見し、単一の正しい数値へ収束したわけではありません。
一方で、成果物の注記には違いが見られました。試作品の資料が確認しているのはCSV（表の値をカンマで区切ったファイル）の取込機能だけです。シフトの変更履歴を保存できる証拠にはなりません。中間評価ではこの不足を追記し、最終一括では同じ明確さでの記載がありませんでした。両条件とも、年換算額を2027年の実現売上と同一視しない注記は追加しました。
| 確認のタイミング | 料金と母数の矛盾 | 最終的なSOM算定値 | 記録保存要件に関する注記 |
|---|---|---|---|
| 中間評価 | 初稿から維持 | 864万円と720万円の二案 | CSV取込のみでは証拠不足と明記 |
| 最終一括 | 初稿から維持 | 864万円と720万円の二案 | 同じ明確さでの記載なし |
この結果から、工程ごとに評価すれば必ず分析精度が上がるとは言えません。業務分析の途中に機械的な検査を挿入しても、誤った母数で計算を通してしまう限界があります。この試行は因果的な優位性や必然的な精度向上を実証したわけではなく、複数試行や人による独立した検証を含めた評価は今後の課題として残ります。
今回のcheck.pyが調べるのは、形式、単位、算術、宣言された地域などです。数値に付けた地域名が正しくても、実際の母数がその地域の倉庫数かまでは保証しません。人が持ち帰る確認事項は、正式な年額、東地域の対象倉庫数、25%と10%の根拠です。
台帳を残し最終結果を別の根拠で確かめる
工程ごとの結果を追うには、読者が別途analysis-ledger.csvという台帳を作ります。このCSVは検証用ZIPの自動出力には含まれません。一行に親子のSkill名と入力ファイルの版、出力先を記録します。評価結果と未確認事項、差戻し先も同じ行へ残します。試行で保存した出力とreview.jsonを転記元にします。
例えば年額の不一致は、計算を繰り返しても解消しません。担当者が料金表の作成者に正式な年額と割引条件を確認し、更新した資料の版を台帳に残します。そのうえで市場算定Skillへ差し戻せば、どの根拠を変更して再計算したか追えます。
料金表の矛盾を解いた後も、需要の仮説には独立した根拠が必要です。例えば類似企業が公表している市場実績と比較したり、想定顧客へ直接聞き取りを行ったりします。対象領域の専門家によるレビューを受けることも、分析の前提の妥当性を確かめる手段となります。
類似市場の実績と食い違った場合は、対象地域、対象年、顧客の定義を先に揃えます。定義が違う数値を平均しても、今回の市場規模の根拠にはなりません。
分析Skillが増え処理が複雑になるほど、人が途中の推論を確認することは難しくなります。生成された算定結果が一致したからといって判断を委ねず、実行記録から不確実な仮定を特定することが重要です。
担当者は需要仮説を支持する証拠、反する証拠、未確認事項を記録から抜き出し、追加調査の順序を決めます。購入意向と保存機能を確かめてから、東地域で実証実験へ進むかを判断します。
よくある質問
Q1. 確認の途中で資料を更新した場合はどこから再実行しますか
途中の確認で前提となる原資料の誤りや不足を見つけ、資料のファイルを直接更新した場合は、その資料を入力とする工程からやり直します。例えばPEST分析の入力資料を書き換えたなら、PESTを担う子Skillから再実行します。
PESTの出力を更新したら、その新しい成果物を後続のフォーサイトや市場算定へ順次渡し直します。担当者が作る台帳の入力欄に、前工程の出力ファイル名と版も残します。再実行時はその対応を親Skillに渡し、後続工程が新しい版を読んだか確かめます。一部の工程だけを不整合な入力のまま再実行しないように注意します。
Q2. 実行時にSkillの定義ファイルを読まない場合はどう対応しますか
この例では.agents/skills/analysis-parent/SKILL.mdが作業フォルダ内にあるかを確認します。ファイルが存在しないか、名前が一致していない可能性があります。親Skillの実行時に入力欄で$analysis-parentと明示して呼び出します。
それでも定義を読み込まない場合は、ファイルパスを直接指示して明示的に読み込ませるか、手動で該当ファイルの内容をプロンプトへ貼り付けて処理を進めます。
Q3. 子Skillの修正が上限に達しても合格しない場合はどうしますか
この例の親Skillは、各工程の修正を一回までと定義しています。一回修正しても合格条件を満たさない場合は、出力と実行記録を保存したうえで採用を保留し、人が引き継ぎます。上限は.agents/skills/analysis-parent/SKILL.mdで確認できます。
人が記録を読み、なぜ仕様を満たせないのかを確かめることが重要です。入力した原資料の矛盾が多すぎる場合や、一つのSkillに対する指示が複雑すぎる場合は、手動で前提条件を整理します。必要に応じて、単独で合否を確認できるようにSkillの分割単位を細かく見直してください。
調査手法について
こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。
Screenshot
調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域（ホワイトスペース）を可視化しながら調査の網羅性を高めていけます。
また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。
ご利用をご希望の方は、こちらよりお申し込みください。
また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。
市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai
コメント