※この記事は「エムティーアイ Blog Summer 2026」の 6/17 の記事です。
こんにちは。スマートコンテンツ事業部の藤木です。
AIにタスクを任せてうまくいかないときには、漠然とタスクの与え方が悪かったとかAIの性能が低いからなどと考えがちです。
難しいタスクについてどこまでAIに任せるべきか、そもそもAIが解決できるのかという悩みを持つこともあると思います。
なので今回は、AIにタスクを渡して解決させるとはどういうことかを考え、実務で必要な観点を考察したいと思います。
目次
AIに与える問題は4つに分類できる
ここではAIに解決させたい問題を以下の4つに分けて考えたいと思います。
- 昔のAIでもそのまま解ける問題
- 現代のAIならそのまま解けるようになった問題(一般知識の問題)
- 今のAIでも工夫しないと難しい問題(より高度な一般知識の問題や、非一般知識の問題)
- 与えられた条件のままでは原理的に解くことができない問題
私たちがAI利用で頭を悩ませるのは、主に3の問題です。どのようにSkillsやプロンプトを設計してこれらの問題を解決するか、というのはAI推進が進むほど考えなければならなくなる問題だと思います。
また、4について考えることもあると思います。今考えている問題はそもそも解くことができるのか？というのは、非常に重要な問題です。解けない問題について考え続けても解決はできません。
1,2についてはAIにそのまま渡しても比較的解けるため、本記事では主な対象にしません。ただし、現在3に位置する問題が将来的に2に変化することは考えられます。そうなるとSkillsやプロンプトに不必要なコンテキストが入ってきてしまう可能性があるので、注意が必要です。
この記事では、考えることが多いであろう3,4の問題について掘り下げて考えていきます。
原理的に解くことができない問題とは
ここでいう「原理的に解くことができない問題」には、要求そのものが矛盾している問題だけでなく、与えられた条件だけでは答えが一意に定まらない問題も含めています。 例えば、以下のようなものは要求そのものが矛盾しています。
- 解が存在しない
- 例：内角の和が200度の平面三角形を作図するプログラムを作成して
このような問題は、AIの性能にかかわらず正しく解くことができません。もし与えてしまっているのであれば、前提条件が何か間違えていると考えられます。
また、私たちの問いの与え方でも一意に解けない問題が生まれます。例えば以下のようなものがあります。
- 前提条件が曖昧
- 例：1辺の長さと1つの角度で平面三角形の面積を求めるプログラムを作成して
- 例：単体テストを作成して
- 判断材料が足りない
- 例：(ドメイン知識を与えずに)このドメインをこうしたい
このような問題は、与え方次第で解けるか解けないかが変化します。例えば単体テストには古典学派とロンドン学派があり、AIが「単体テスト」をどのように解釈するかによって結果が大きくブレることになります。結果がブレるのも織り込み済みの場合や、特にアイデアもなく思考コストをかけずにAIに任せたいという発想であれば問題はないと考えられますが、もし私たちが明確な答えを求めているのならば、解釈の余地を減らす条件を与えるべきです。
ドメインについても、必要な情報がないとAIは判断できません。例えば「CARADA」と「CARADA健診予約」は別のものなのですが、AIはそれを判断できずに混ぜて思考してしまうことがあります(CARADA=CARADA健診予約の略称なのでは？と考えることは合理的な考えです)。
これらは本質的には3の「難しい問題」ですが、表現によっては4の「解けない問題」になってしまうということです。 では、どうすれば解ける問題として表現できるでしょうか。
解ける問題に近づけるには
実務で重要なのは、4の「解けない問題」として表現されているものを3の「難しい問題」に落としたうえで、その問題を工夫して解かせることです。
解ける問題に近づけるためには、以下のような観点が有効だと思います(ほかにもたくさんあると思います)。
- 「解けない問題」の表現を「難しい問題」に落とす
- 別の解釈ができる可能性を減らす
- 必要な情報を与える
- 「難しい問題」を解く
- 難しい問題は段階に分解する
- 内部の自由度を、外側の検証で制御する
順番に見ていきます。
1-1. 別の解釈ができる可能性を減らす
まず大切なことは、求めているものと別の解釈ができてしまう可能性を減らすことだと思います。例えば単体テストの作成タスクを「古典学派の考え方で」「編集されているソースファイルに対して」のように5W1Hなどを用いて対象を明確にしていくと、想定外の挙動が減ると考えられます。
参考：プロンプトのベストプラクティス - Claude API Docs
Claudeを、優秀だが新入社員で、あなたの規範やワークフローについての文脈を持っていない人だと考えてください。何を望んでいるかを正確に説明すればするほど、結果は良くなります。
参考：成功基準の定義と評価の構築 - Claude API Docs
優れた成功基準は以下の特性を備えています。
具体的であること： 達成したいことを明確に定義します。「良いパフォーマンス」ではなく、「正確な感情分類」のように具体的に指定します。
測定可能であること： 定量的な指標または明確に定義された定性的な尺度を使用します。数値は明確さとスケーラビリティを提供しますが、定量的な指標と併せて一貫して適用される場合、定性的な指標も価値があります。
- 倫理や安全性といった「曖昧な」トピックでも定量化できます。
1-2. 必要な情報を与える
1つ目と重なる部分も大きいですが、必要な情報がないとAIは混乱します。 例えばAzure DevOpsで複数の組織やプロジェクトがある場合、AIは関係ないところに情報を探しに行って迷ってしまうことがあります。私たちはついAIが知らないことを忘れがちですが、暗黙知も与えることでAIの問題の解決が容易になると思います。
2-1. 難しい問題は段階に分解する
これがやはりキモです。「難しい問題」に落としている段階でもある程度分解されてきますが、それでも問題が難しい場合は、さらに分解する必要があります。 学力テストの数学で、大問の中に誘導があるようなものです。ぱっと見は解けるのかすら判断できない問題でも、どっちに行けばいいかがわかれば解ける確率は上がります。
複雑な問題を小さな部分問題に分解するLeast-to-Most Promptingや、複数の候補を探索・評価するTree of Thoughtsなど、問題の解き方を構造化することで性能を改善する研究はいくつかあります。
例えばHUMORCHAINは、画像に対するユーモアキャプション生成を多段階推論の問題として扱った研究です。単に「面白い一言を作る」のではなく、視覚意味解析、ユーモア理論・心理学に基づく推論、評価器による検証を組み合わせています。
これは、曖昧に見える創造的タスクでも、処理手順や評価観点を明示することで、AIにとって扱いやすい問題に近づけられる例だと考えられます。
参考：
「AIにとって扱いやすい問題に近づける」と聞くと、誰でも少し工夫すればできるように思えます。しかし、複雑なタスクではそう単純ではありません。どこまでをAIに任せ、どこで人間が条件を与え、どの段階で検証するかを設計する必要があります。これは、対象業務への理解と、問題を分割する論理的な力の両方が求められる作業です。
蛇足ですが、Chain of Thoughtも近い発想だと思います。最終回答だけを求めるのではなく、中間的な推論過程を明示させることで、複雑な問題を扱いやすくする考え方です。
2-2. 内部の自由度を、外側の検証で制御する
すべての中間判断を厳密に固定するのではなく、最終的に満たすべき条件を外側に置く、という考え方です。例えば単体テストについては、細かい設計方針には一定の自由度を残し、重要なユーザーフローはE2Eテストで保証します。これにより、単体テストの設計を過度に細かく指定しなくても、全体として目的を達成できるようにします。同様にコードの細部についても、事前にすべて指定するのではなく、単体テスト、静的解析、レビュー観点などの検証条件を満たすかどうかで判断します。
当然小さいゴールも厳密に決められるほうがコントロールはしやすいのですが、その分手間がかかります。どのゴールまで求めるかを明確にすることにより、求める品質に効率よく到達させることができます。
参考：Prompt guidance | OpenAI API
GPT-5.5 works best when prompts define the outcome and leave room for the model to choose an efficient solution path.
要約：GPT-5.5は、プロンプトが結果を定義し、モデルが効率的な解法を選択する余地を残すときに最も効果的に機能します。
(私の感覚ですが、モデルの性能が上がるほどこの傾向は強くなると感じます)
補足：モデルの性能向上によるタスクの易化
問題を4つに分類したところでも触れたのですが、モデルの性能も問題解決において大切になってきます。ご存じのように、モデルの性能が上がるとできることが増えていきます。モデルの性能が低かったときには工夫しないと解けなかった問題が、性能の高いモデルでは工夫無しに解けるようになります（ベンチマークのスコア上昇など）。なので、現在工夫しないと解けない問題が、将来は何の工夫も無しに解ける可能性もあります。 それは良いことばかりではなく、過去のプロンプトがノイズになってしまう可能性もあることを覚えておく必要があります。
参考：Prompt guidance | OpenAI API
Avoid carrying over every instruction from an older prompt stack. Legacy prompts often over-specify the process because earlier models needed more help staying on track. With GPT-5.5, that can add noise, narrow the model’s search space, or lead to overly mechanical answers.
要約：古いプロンプトスタックをそのまま引き継ぐと、現在のモデルではノイズになったり、探索範囲を狭めたりする可能性があるから避けるべきである。
なお、上に述べた2-2はこの事実にも強いと考えられます。コントロールする部分を制限することで、モデルの進化の恩恵を受けつつ、目的を達成することができます。
実務を振り返る
このように考えると、AI利活用において「これはAIで解決できるのか？できないのか？」というのは割と判断しやすくなるのではないかと思います。
実務で遭遇する問題の多くは、完全に解けない問題というより、条件不足や分解不足によって解けない形になっている場合が多いのではないかと思います。AIから望んだ出力が得られない場合、正しく問題を分割できているか？もしくは過剰になっていないか？と考えるのが良いと感じます。
Skillsにおいて発生する衝突や期待しない出力についても、問題の分解がうまくいっていないことが多いように感じます。たとえば「この問題にはこのSkillを使うべき」という対応関係も、条件を明確にすればAIに判断させられる問題に近づくはずです。逆にいえば、Skill同士が衝突する場合は、どの条件でどのSkillを使うべきかが十分に定義されていない可能性があります。
ドキュメント整理も近いものがあると思います。AIがドキュメントを探索するのは解けない問題を解けるようにするためであり、ドキュメントを順番に辿った結果、適切な情報にたどり着けるようにするという問題設計がAI時代に求められる情報整理ではないでしょうか。
モデルの性能の変化によって解ける問題が変化するというのも大切な観点です。現在使っているSkillsには将来不要になるものが含まれる可能性があるため、そのSkillsがどれだけ陳腐化しやすいかは把握する必要があると思います。
おわりに
今回はAIに問題を解かせるにあたって、意外と忘れがちなことを備忘録もかねてまとめました。考えてみれば当然のことばかりだと思いますが、時間に追われていたり疲れているとついつい妥協してしまいがちなことでもあります。
AIにタスクを任せるとは、単に指示を書くことではないと思います。 AIが使う情報、許す解釈、辿る手順、止まる条件、外側の検証方法を設計することではないでしょうか。 その意味で、Skillsやドキュメント整理は、AIに知識を渡す作業であると同時に、曖昧な業務をAIが解ける問題へ変換する作業でもあると考えています。
ぜひ、AIの使い方について改めて考える一助となれば幸いです。ここまで読んでいただき、ありがとうございました。
