長いAIスキルほど回答が薄くなる｜中間成果物でつなぐ分割ワークフロー

ここで問題になるのは、AIスキルの行数だけではありません。調査から最終チェックまでを一文の中へ詰め込むと、回答は一応まとまっていても、どの根拠がどの判断を支えているのか見えにくくなります。仮想的な例を使いながら、同時に扱う判断の数を見直します。

長い入力では、情報の位置や入力長によって性能が変わり得ます。Lost in the MiddleやContext Length Alone Hurts LLM Performance Despite Perfect Retrievalは、長文を受け取れることと、情報を均等に使えることが別だと示す研究です。ただし、長いAIスキルが必ず失敗するという意味ではありません。

対応の軸は、指示文の行数を減らすことではありません。AIが同時に行う判断を分け、工程ごとに入力、出力、合格条件、未確認事項をファイルへ残します。SKILL.mdは詳細な知識を詰め込む倉庫ではなく、工程と参照先を示す入口として使います。

最後の統合では、根拠、前提、反対意見、未確認事項を最終結果へ戻します。分解は常に正解ではなく、依存関係が強い課題では元のまとまりを保つほうがよい場合もあります。狙えるのは回答の正確さを保証することではなく、浅さがどの工程で生まれたかを検証しやすくすることです。

長いAIスキルは行数より同時に扱う判断が問題になります

「資料を集め、複数の案を比較し、反対意見を探し、結論を書き、最後に誤りがないか確認してください」。このような指示を一度にAIへ渡す場面があります。仮想的な例ですが、調査から最終チェックまでを一文の中へ詰め込むと、回答は一応まとまっていても、どの根拠がどの判断を支えているのか見えにくくなります。

AIスキルとは、AIに専門的な手順や判断方法を渡すファイル、またはまとまった指示のことです。長いAIスキルが扱う「調査」「比較」「評価」「文章化」を、AIが同じ作業空間で同時に保持する設計に問題がないかを確認します。どうやら、難しさは情報量そのものより、複数の合格条件を同じ場所で守ろうとする点にあります。

長い入力を受け取れることと、入力内の情報を同じように使えることは別です。Lost in the Middleの研究では、複数の文書に含まれる関連情報の位置を変えると、質問への回答性能が変わりました。特に、入力の先頭や末尾ではなく中央付近にある情報が使われにくくなる傾向が報告されています。長い指示が必ず失敗するという結論ではなく、情報の置き場所が結果に影響し得るという限定された示唆です。

Context Length Alone Hurts LLM Performance Despite Perfect Retrievalは、関連情報を正しく取り出せる条件でも、入力が長くなると数学、質問応答、コーディング課題の性能が下がる実験結果を報告しました。対象となった実験では、5種類のモデルの性能低下が13.9〜85%の範囲で観測されています。この数字を一般の業務へそのまま移すことはできませんが、「検索さえ正しければ長文でも問題ない」とは言い切れない根拠になります。

さらに、調査と評価を同時に要求すると、AIは調査結果を残すことより最終回答を整えることへ寄る可能性があります。これは長文研究が直接測定した因果ではなく、長文入力の性質を業務設計へつないだ仮説です。ただ、最終回答が浅かったときに、情報不足なのか、比較の基準が曖昧だったのか、反対意見の確認が抜けたのかを判別できないという問題は残ります。

だからといって、長いAIスキルを短く書き直せばよいわけではありません。短縮すると必要な判断条件まで落ちることがあります。では、何を境界にすればよいのでしょうか。私がこの問題を考えるとき、行数よりも「一つの工程でAIが何を決め、何を次へ渡すのか」を先に分けたほうが、浅さの原因を追いやすい気がしてきます。

判断項目を小さく分けて工程の役割を決めます

分割の単位を文章の長さに置くと、短い指示がいくつも並ぶだけになります。分ける対象は、AIが行う判断です。調査する、主張を抜き出す、反対の根拠を探す、採用する情報を評価する、といった判断ごとに、入力と出力を決めます。

Plan-and-Solve Promptingは、いきなり答えを出すのではなく、先に計画を作って小さな課題（下位課題）を処理する方法を提案しました。Decomposed Promptingは、複雑な課題を小さな下位課題に分け、それぞれへ専用の処理を割り当てる方法を説明しています。いずれも、長いAIスキルを短くする方法ではなく、複雑な作業を判断単位へ分ける考え方です。

ただし、最初からすべてを細かく分ける必要はありません。ADaPTは、実行できない下位課題に当たったとき、必要な部分だけをさらに分解する設計を扱っています。分割を増やすかどうかを、実行中の失敗で判断する考え方です。研究論文が示した成功率を、一般の業務改善率として使うことはできません。実務へ応用できるのは、分解の粒度を固定しないという判断方法です。

実務で工程を決めるときは、次の5項目を一つずつ書き出します。

1. AIが読む入力は何か。資料、検索結果、前工程のファイルなどを明記します。
2. AIが判断する対象は何か。事実の採用、分類、比較、反証の確認などを一つに絞ります。
3. AIが書き出す成果物は何か。候補一覧、主張と根拠の対応表、未確認事項など、次工程が読める形にします。
4. どの条件で合格とするか。出典がある、反対根拠を確認した、判断保留を明記した、といった条件を置きます。
5. 合格しなかったとき、どの工程へ戻るか。調査へ戻るのか、評価だけをやり直すのかを決めます。

仕事の種類によって、最初に切り出す判断は変わります。企画担当者なら、資料を集める工程と案を評価する工程を分けます。調査担当者なら、事実の確認と反対根拠の探索を分けます。評価を担う人なら、比較表を作る前に「何を合格とするか」をファイルへ残します。同じ分割手順を全員へ当てはめるのではなく、判断が混ざって困った場面から境界を作ります。

たとえば「新しい企画を調べて評価する」という一文を、そのまま5個のプロンプトへ切り分けるだけでは不十分です。調査工程が集めた情報を、分析工程がどの項目へ変換するのかが必要です。調査工程の出力に「出典URL、確認できた事実、まだ推測の部分」を含めれば、次の工程は事実と推測を混ぜずに比較できます。

この分け方には、作業を増やす面もあります。工程ごとにAIを呼び出せば、実行時間や利用量も増えます。分解の価値は、いつでも回答品質を上げることではなく、どの判断で失敗したかを人間が確認できる状態を作ることにあります。依存関係が強い課題では、無理に分けない判断も必要です。

工程ごとの結果を中間成果物としてファイルに残します

工程を分けても、AIとのやり取りの中だけで結果を受け渡すと、どの時点で判断が変わったのかを追いにくくなります。そこで、工程ごとの出力をファイルとして残します。ファイルは作業のメモではなく、次の工程が何を受け取り、何を疑い、何をまだ確認していないかを示す境界です。

この設計に近い考え方として、最終結果だけを評価するoutcome supervision（結果を評価する方法）と、途中の推論手順にも評価を置くprocess supervision（工程を評価する方法）を分けたLet’s Verify Step by Stepがあります。同論文は数学の推論課題を対象に、途中の手順へ人手の評価を付ける方法を研究しました。数学のモデル学習に関する結果なので、調査ファイルを保存すれば同じ改善が起きるという証明ではありません。それでも、最終回答だけを見ず、途中の判断に確認点を置く方向は参考になります。

ファイルの来歴（どの処理から生まれたかの記録）を考えるときは、W3CのPROV-DMも役立ちます。PROV-DMは、成果物、処理、処理を担う主体、ある成果物から別の成果物が生まれた関係を表すモデルです。W3CがAIスキルの保存形式を決めているわけではありません。この設計では、入力、処理、出力、派生関係を意識する参考として扱います。

実際に使うファイルには、次のような役割を持たせます。ファイル名や分割数に正解があるのではなく、各工程の境界が読めることが目的です。

各ファイルの先頭に、少なくとも「入力」「この工程の判断」「出力」「未確認事項」「失敗時の戻り先」を置きます。たとえば主張対応表の根拠URLが空なら、文章化へ進まず、事実一覧の工程へ戻します。AIが出した内部の思考を保存するのではありません。人間と次の工程が検証できる外部成果物を残します。

中間成果物を細かくしすぎると、ファイルの読み書きと統合の負担が増えます。粗すぎると、結論と根拠が一つの文章に戻ってしまいます。最初から理想の粒度を決めるより、最終回答で確認したい失敗を一つ選び、その失敗を見つけられる境界から作ると現実的です。

なお、Workflow-to-Skillは、ワークフローの構造、実行時の意味、実行時の補足を分ける中間表現を提案しています。これは一つのプレプリントによる提案で、業務へそのまま適用できると確認されたものではありません。ここで参考にするのは、工程の順番だけでなく、合格条件や実行時の注意も別の情報として持つという発想です。

SKILL.mdを目次と制御層にして参照範囲を絞ります

中間成果物が増えると、今度は「どのファイルを、どの工程で読むのか」が分からなくなります。ここで入口になるのがSKILL.mdです。SKILL.mdは、AIスキルの名前や説明、手順を置くMarkdown形式のファイルです。この設計では、詳細な知識をすべて詰め込む本文ではなく、工程の目次と制御層として設計します。

Agent Skillsの公式概要では、Skill（特定の作業向けに手順と資料をまとめたもの）のフォルダにSKILL.mdを置き、必要に応じてscripts、references（参照資料）、assets（素材）などのリソースを同梱できる形が説明されています。仕様は、起動時に名前と説明を見て、関連すると判断したSkillの本文を読み、必要なときに同梱リソースを読むprogressive disclosure（段階的な情報開示）を示しています。最初からすべての資料をAIへ渡さず、必要な段階で参照する設計です。

入口のファイルには、次の情報を置きます。

• このSkillが対象にする作業と、対象にしない作業
• 工程の順番と、各工程が読む入力ファイル
• 各工程が書き出すファイルと、合格条件
• 判断が保留になった場合の戻り先
• 詳細な資料、テンプレート、スクリプトの参照先

たとえば、調査工程のreferencesだけを読むべき場面で、評価用の資料まで常に読み込ませる必要はありません。SKILL.mdが「調査工程は事実一覧を作り、評価工程は主張対応表と反対根拠を読む」と示せば、参照範囲の選択を工程のルールへ落とせます。必要な資料を読んだかどうかは、実行ログや成果物の入力欄で確認します。

Skill descriptionsの最適化ガイドは、description（Skillが対象にする場面の説明）がSkillを読み込むかどうかに影響し、説明が広すぎると不要な場面で発火し、狭すぎると必要な場面で発火しないとしています。この運用では、descriptionへ「いつ使うか」だけでなく「いつ使わないか」も書き、should-trigger（発火してほしい例）とshould-not-trigger（発火させない例）のテストを用意します。公式仕様が特定の発火率を保証しているという意味ではありません。

SKILL.mdを目次と制御層にする設計は、Agent Skills仕様の正式な用語ではありません。仕様が示すのはファイル形式と段階的に読む考え方です。どの互換クライアントがいつ本文を読み、referencesをどう扱うかまで同じとは限りません。実務では、SKILL.mdの記述だけで成功扱いにせず、実際にどの工程とファイルが使われたかを確認してください。

入口の説明を短くすること自体が目的になると、合格条件や戻り先が消えるため、短さではなく工程を迷わずたどれることを基準にします。

最後の統合で根拠と未確認事項を戻します

中間成果物を作ると、最後にファイルをつなぐだけで完成するように見えます。しかし、統合工程は貼り合わせではありません。主張と根拠、分析と前提、評価と未確認事項をもう一度対応づけ、途中で失われた条件がないかを調べます。

Building effective agentsは、前の呼び出しの出力を次の呼び出しへ渡すprompt chaining（前のAI出力を次の処理へ渡す方法）と、途中へプログラム上のチェックを置く考え方を説明しています。工程を固定的に分けられる課題では、各工程を単純にする代わりに、実行時間や利用コストが増えるとされています。分ける代わりに、確認できる境界を増やす設計です。

統合時は、次の順番で確認します。

1. 採用した主張ごとに、根拠ファイルの該当箇所を結びます。
2. 根拠が示す範囲を超えて、主張を一般化していないか確認します。
3. 反対根拠、前提、未確認事項を削らず、最終出力に残すか判断します。
4. 工程ごとの合格条件を満たしたかを再確認します。
5. 矛盾が解けない場合は、最終回答で断定せず、前の工程へ戻します。

分割には明確な限界もあります。Decomposition Does Not Helpは、因果関係を意味の近いまとまりへ分けてから統合すると、直接プロンプトより性能が下がる例を報告しています。意味が似ていることと、原因と結果の順序が保たれることは同じではありません。Lost in Decompositionも、文脈に強く依存する課題では、分解が依存関係の把握を妨げる可能性を指摘しています。

分解の限界を踏まえ、分解を続ける条件だけでなく、止める条件もSKILL.mdへ置きます。小さな課題が独立して判定できない場合、成果物の境界で合格条件を置けない場合、統合時に根拠や不確実性を戻せない場合は、工程を一つに戻す候補です。依存関係を保ったまま大きな単位で評価したほうが、結果を説明しやすいことがあります。

Select-Then-Decomposeは、タスクの特徴、分解方法、実行モデルの組み合わせを選び、実行と検証を閉じたループで扱う方法を提案しています。ここでも、分解は最初に決めて終わる設定ではありません。課題の性質とコストを見て、分けるか、分けないか、戻すかを選びます。

長いAIスキルの回答が浅いとき、工程分割と中間成果物でできるのは、浅さをなくすことではなく、浅さがどの工程で生まれたかを調べやすくすることです。調査が足りなかったのか、比較軸がずれたのか、統合で条件を落としたのかが見える。浅さの原因を追跡できる範囲までを、この設計として提案できます。

よくある質問（FAQ）

Q1. 長いAIスキルは短く書き直せば改善しますか？

行数を減らすだけでは改善を保証できません。必要な判断条件や合格条件まで削ると、回答の浅さを確認しにくくなります。行数ではなく、AIが一つの工程で何を判断し、何を次へ渡すかを分けてください。

Q2. AIスキルは何を単位に分割すればよいですか？

文章の長さではなく、判断の種類を単位にします。調査、主張の抽出、反対根拠の確認、評価、統合のように、入力、判断対象、出力、合格条件を一組で定義します。

Q3. 中間成果物をファイルに残すと、AIの内部処理を監査できますか？

AIの内部処理をそのまま監査できるわけではありません。ファイルに残せるのは、入力、出典、判断、未確認事項、次工程への受け渡しといった外部成果物です。最終回答だけを見るより、どの工程で問題が起きたかを調べる手がかりになります。

Q4. SKILL.mdはどのように設計すればよいですか？

対象にする作業、工程の順番、各工程の入力と出力、合格条件、失敗時の戻り先、詳細資料の参照先を置きます。Agent Skillsの仕様が示す段階的な読み込みを、実務の入口設計へ適用するイメージです。どのクライアントでも同じ動作をするとは限らないため、実行ログで確認します。

Q5. 工程を分ければ、いつでも回答の精度が上がりますか？

上がるとは限りません。因果関係や文脈への依存が強い課題では、分解と統合によって必要な関係が失われることがあります。各工程に独立した合格条件を置けない場合や、統合時に根拠を戻せない場合は、分割を止める候補です。

Q6. 最初の一回は何から試せばよいですか？

普段使っている長い指示を一つ選び、指示を短くする前に判断の種類を書き出します。次に、各判断へ「入力、出力、合格条件、未確認事項、戻り先」を一行ずつ付けます。最初から細かく分けず、回答が浅くなった箇所を次の実行で確認できる程度の粒度から始めると、統合コストを抑えられます。

調査手法について

こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。

Screenshot

調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域（ホワイトスペース）を可視化しながら調査の網羅性を高めていけます。

また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。

ご利用をご希望の方は、こちらよりお申し込みください。

また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。

冨田到

市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai

www.deskrex.ai/