LLMタスク分類ツリー
概要
LLMタスク分類ツリー
LLM（大規模言語モデル）に依頼できるタスクを体系的に分類したガイドだ。タスクの性質ごとに章を分け、それぞれの難易度・必要な推論レベル・推奨モデル・注意点・具体例を示している。自分がやりたいことがどのカテゴリに属するかを把握することで、最適なモデル選びやプロンプト設計に役立てることができる。
なぜこの分類が重要か
LLMを使いこなすうえで、タスクの性質を正確に把握することはモデル選択・プロンプト設計・ツール組み合わせのすべてに影響する、基礎的な判断である。
コストと品質のトレードオフという観点では、フォーマット変換のような軽量タスクに最高性能モデルを充てるのはコストの無駄であり、逆に多段階推論が必要な論理パズルを軽量モデルに任せると品質が崩壊する。タスクの複雑さに応じてモデルを適切にスケールさせることが、合理的な運用の前提となる
有効なプロンプト手法もタスク種別に依存する。推論系タスクではChain-of-Thought（段階的思考の言語化）が正答率を大きく引き上げるが、情報抽出系タスクでは出力フォーマットの明示の方が重要になる。タスクの性質を誤認すると、本来有効な手法が機能しない。
補助ツールの要否判断にも、分類の把握が直結する。最新情報を扱うタスクにはRAGや検索機能が必須であり、データ分析にはコード実行環境が必要になる。モデル単体で解決しようとするか、ツールと組み合わせるかは、タスク分類から導かれる設計判断である。
1. 情報取得・確認系
すでに世の中に存在する情報を「調べて返す」ことが中心のタスク群だ。求められる正確性のレベルや調査範囲の広さによって、3つに細分化される。
1.1 質問・技術的確認（推測禁止）
既知の事実や技術的な仕様をピンポイントで確認するタスクだ。モデルには推測や憶測を一切挟まず、正確な情報だけを返すことが求められる。辞書や公式ドキュメントを引くような使い方に近いイメージである。
難易度は低〜中で、推論はほぼ不要（内部の知識検索が主体）のため、Haiku や GPT-3.5 などの軽量モデルでも十分対応できる。ただし、最新のデータや時事情報が絡む場合は、RAG（検索拡張生成）や Web 検索機能の併用が必須だ。
具体例としては「Python のリスト内包表記の文法を教えて」「HTTP ステータスコード 403 の意味は？」「日本の消費税率は現在何パーセント？」などがある。
1.2 調査・リサーチ
複数の情報源を横断的に調べ、得られた情報を統合・分析して包括的な知見を提供するタスクだ。1.1 の「質問」が単発の事実確認であるのに対し、こちらは広く深く調べたうえで全体像をまとめる作業にあたる。
難易度は中〜高で、情報の統合・分析・信頼性評価といった高度な推論が必要だ。Sonnet 以上の中〜高性能モデルが推奨される。多段階の検索や、情報源の信頼性を見極めるプロセスが品質を大きく左右する。
具体例としては「2026 年の AI 規制に関する各国の動向をまとめて」「電気自動車の普及が電力網に与える影響を調べて」「リモートワークの生産性に関する最新研究を調査して」などがある。
1.3 事実検証（ファクトチェック）
提示された情報や主張について、その真偽を証拠に基づいて判定するタスクだ。単に情報を探すだけでなく、論理的整合性の確認、証拠の評価、矛盾点の検出など、批判的思考が中心になる。
難易度は高く、高性能モデルに加えて検索機能の組み合わせが推奨される。結果の信頼性が特に重要で、必ずソース（出典）の確認を伴わせる必要がある。
具体例としては「この記事の統計データは正確か検証して」「SNS で拡散されているこの主張の真偽を確かめて」「製品レビューに記載された仕様が公式情報と一致するか確認して」などがある。
2. 思考支援・対話系
ユーザーの思考やアイデアの整理を対話的にサポートするタスク群だ。情報取得系とは異なり、正解が一つに定まらない場面が多く、文脈を読み取る力や創造的な発想力が求められる。
2.1 相談・壁打ち（推測が必要）
ユーザーの悩みや漠然とした考えに対して、対話を通じて思考の整理や新たな気づきを促すタスクだ。正確な情報を返すことよりも、相手の意図を推測し、共感しながら問いかけることが重要になる。
難易度は中程度で、文脈の理解・共感・推測といった中レベルの推論が必要だ。Sonnet クラスの中性能モデルが適している。対話のなかで一貫性を保ちつつ、文脈を途切れさせない工夫が品質の鍵になる。
具体例としては「キャリアチェンジすべきか迷っている、話を聞いて」「新しいサービスのアイデアがあるけど実現可能か相談したい」「プロジェクトの進め方で悩んでいる、一緒に考えて」などがある。
2.2 アイデア生成・ブレインストーミング
新しい発想やアイデアを多角的に提案し、創造的思考を広げるタスクだ。質より量を重視して発散的に出す段階と、出てきた案を組み合わせたり磨いたりする段階の両方が含まれる。
難易度は中程度で、創造的な発散思考やアイデアの組み合わせ能力が求められる。中〜高性能モデルが推奨され、特に独創性を重視したい場合は高性能モデルを使うと質が上がる。
具体例としては「環境に優しい新しいパッケージのアイデアを 10 個出して」「オンラインイベントを盛り上げる企画案を考えて」「既存のカフェを差別化する斬新なコンセプトを提案して」などがある。
2.3 ロールプレイ・対話シミュレーション
特定の役割や人物をモデルに演じさせ、シナリオのシミュレーションや実践練習を行うタスクだ。面接練習やクレーム対応の模擬演習など、実際の場面を安全に試せる点が強みだ。
難易度は中程度で、キャラクターの一貫性の維持、文脈の保持、演じる役割の深い理解が必要だ。中〜高性能モデルが推奨される。長いやり取りを続ける場合はコンテキスト長の制限に注意し、要点を随時要約するなどの工夫が求められる。
具体例としては「面接官の役になって模擬面接をして」「クレーム対応の練習相手になって」「技術的な質問に答える顧客サポート役を演じて」などがある。
2.4 情報設計・構造化
情報を効果的に伝えるための論理構造やストーリーの流れを設計するタスクだ。プレゼンテーションの骨子、提案書の章立て、レポートの構成、Web サイトの情報アーキテクチャ（IA）などが該当する。見た目のデザインではなく、「何をどの順番で伝えるか」という伝達の流れを考える点が特徴だ。
難易度は中〜高で、情報の階層化、ストーリー設計、受け手の理解度の想定、説得構造の組み立てといった高度な推論が求められる。Sonnet 以上の中〜高性能モデルが推奨される。
具体例としてはプレゼン骨子の作成、提案書の章立て設計、ドキュメントの情報アーキテクチャ設計、カリキュラム構成、Web サイトの情報構造（IA）設計などがある。
3. 計画・分析系
目標達成のための計画を立てたり、複数の選択肢を比較評価したり、データから傾向を読み解いたりするタスク群だ。いずれも構造的に考え、根拠をもって判断する能力が求められる。
3.1 計画（タスクリスト作成）
目標達成に必要な手順やタスクを洗い出し、構造化して実行可能な計画に落とし込むタスクだ。マイルストーンの設計、優先順位づけ、担当者の割り振りなど、プロジェクトマネジメントに近い作業が含まれる。
難易度は中〜高で、構造化思考、優先順位づけ、タスク間の依存関係の把握といった高度な推論が必要だ。Sonnet 以上の中〜高性能モデルが推奨され、複雑な大規模プロジェクトの場合は Opus クラスの利用が望ましい。
具体例としては「新規 Web サービス立ち上げのマイルストーンを作成して」「3 ヶ月で英語力を向上させる学習計画を立てて」「イベント開催までのタスクリストと担当者割り振りを設計して」などがある。
3.2 比較・評価
複数の選択肢や対象を多軸で比較し、トレードオフを整理して判断材料を提供するタスクだ。単に並べるだけでなく、評価基準の設定やそれぞれの長所・短所の分析を含む点がポイントだ。
難易度は中〜高で、多軸分析、トレードオフの評価、評価基準の設定といった中〜高レベルの推論が必要だ。中〜高性能モデルが推奨され、複雑な意思決定を支援する場合は高性能モデルの方が精度の高い比較ができる。
具体例としては「クラウドサービス 3 社を価格・性能・サポートで比較して」「プログラミング言語の選定基準を示して評価して」「CMS 候補の機能・コスト・拡張性を比較表にして」などがある。
3.3 データ分析・統計処理
データを統計的に処理・分析し、傾向やパターンを抽出して解釈するタスクだ。数値データの集計にとどまらず、そこから何が読み取れるかを言語化するところまでが範囲に含まれる。
難易度は中〜高で、統計的推論、結果の解釈、可視化といった高度なスキルが求められる。中〜高性能モデルに加えて、Code Execution（コード実行環境）との組み合わせが推奨される。高度な統計手法を使う場合は高性能モデルが必須だ。
具体例としては「売上データから季節トレンドを分析して」「A/B テストの結果の統計的有意性を検証して」「ユーザー行動ログから離脱ポイントを特定して」などがある。
4. 生成・創作系
ゼロから新しいコンテンツを作り出すタスク群だ。コード、画像、文章といった成果物そのものの生成と、学習用コンテンツの作成に分かれる。
4.1 生成（ソースコード・画像・小説）
何もない状態から新しいコンテンツを創造するタスクだ。ソースコードの実装、画像やデザインの生成、小説やシナリオの執筆など、幅広い成果物が対象になる。
難易度は内容によって中〜高と幅があり、構造設計力、創造性、一貫性の維持が求められる。推奨モデルも成果物の性質によって異なり、定型的なコード生成であれば軽量〜中モデルで十分だが、複雑なアーキテクチャ設計や品質にこだわる創作物では高性能モデルが望ましい。なお、要件をどれだけ明確に定義できるかが、成果物の品質に直結する。
具体例としては「ユーザー認証機能付きの REST API を実装して」「企業ロゴのデザイン案を 3 パターン生成して」「SF 短編小説（5000 字）を書いて」などがある。
4.2 教育・チュートリアル作成
学習者のレベルに合わせて段階的な説明や具体例を作成し、理解を促進するタスクだ。単なる情報提供ではなく、「どう教えれば伝わるか」という教授法の設計が含まれる点が特徴だ。
難易度は中〜高で、段階的な説明の構築、適切な例示の生成、学習者のレベルに応じた難易度調整が必要だ。中〜高性能モデルが推奨される。対象者のレベルに合わせて説明の粒度や用語の選び方を調整する能力が品質を左右する。
具体例としては「初心者向け Git 入門チュートリアルを作成して」「機械学習の基礎を中学生にも分かるように説明して」「React フックの使い方を実例付きで段階的に解説して」などがある。
5. 評価・改善系
すでに存在する成果物（コード、文章、システムなど）を評価し、問題点の指摘や改善を行うタスク群だ。生成系が「作る」フェーズだとすれば、こちらは「磨く・直す」フェーズにあたる。
5.1 レビュー
コード、文章、デザインなどの成果物を基準に照らして評価し、改善点を具体的に指摘するタスクだ。何が良くて何が問題なのかを根拠とともに説明する批判的思考が中心になる。
難易度は中〜高で、批判的思考、基準への適用、潜在的な問題の発見といった高度な推論が必要だ。中〜高性能モデルが推奨されるが、コードレビューやセキュリティ監査のように見落としが重大なリスクにつながる場面では、高性能モデルの使用が強く推奨される。
具体例としては「この Python コードのセキュリティ脆弱性を指摘して」「プレゼン資料の論理構成と視覚的訴求力をレビューして」「商品説明文の分かりやすさと説得力を評価して」などがある。
5.2 文章改善（校正・リライト）
既存の文章を文法、スタイル、明瞭性の観点から改善し、より良い表現に書き換えるタスクだ。元の意図を保ちながら、読みやすさや説得力を向上させることが目的だ。
難易度は中程度で、文法やスタイルの判断、表現力といった中レベルの推論で対応できる。Sonnet クラスの中性能モデルで通常は十分だが、高度なスタイル調整（文体の統一、特定のトーンへの変換など）が必要な場合は高性能モデルの方が良い仕上がりになる。
具体例としては「このメールをより丁寧な表現に書き直して」「技術文書を非エンジニアにも分かる文章に改善して」「プレスリリースをより簡潔で印象的な文章にして」などがある。
5.3 デバッグ・トラブルシューティング
エラーや不具合の原因を特定し、解決策を提案するタスクだ。目に見える症状から見えない原因を突き止める、いわば「逆方向の推論」が求められる。
難易度は中〜高で、因果関係の推論、仮説の検証、システム全体の理解といった高度な推論が必要だ。高性能モデルの使用が推奨され、複雑なシステムにまたがる問題の場合は最高性能モデルの利用が望ましい。
具体例としては「このエラーメッセージの原因と解決方法を教えて」「データベース接続が遅い原因を特定して」「デプロイ後に発生した 500 エラーをトラブルシュートして」などがある。
6. 抽出・変換系
既存のデータやコンテンツから必要な情報を取り出したり、別の形式に変換したりするタスク群だ。創造性よりも正確性と効率性が重視され、比較的軽量なモデルで対応できるものが多い点が特徴だ。
6.1 要約・与えた情報の説明
長い文章や複雑な情報を圧縮して要点を抽出するタスク、あるいは難解な内容を分かりやすく噛み砕いて説明するタスクだ。元の情報を正確に保ちつつ、短くまとめる力が求められる。
難易度は低〜中で、抽出・圧縮・再構成といった低〜中レベルの推論で対応できる。軽量〜中モデルで十分だが、長文の技術文書や専門的な論文を扱う場合は中性能以上のモデルが推奨される。
具体例としては「この論文を 3 段落で要約して」「会議の議事録から決定事項だけを抽出して」「複雑な利用規約を一般ユーザー向けに分かりやすく説明して」などがある。
6.2 データ抽出・構造化（NER 含む）
非構造化データ（自由記述のテキスト、画像など）から特定の情報を抜き出し、JSON や CSV などの構造化されたフォーマットに変換するタスクだ。固有表現認識（NER：人名・組織名・地名などの自動識別）もこのカテゴリに含まれる。
難易度は低〜中で、パターンの適用と認識が中心のため推論レベルは低め。軽量〜中モデルで対応可能だが、医療・法律などの専門分野を扱う場合は中性能以上のモデルが望ましい。
具体例としては「名刺画像から氏名・会社名・メールアドレスを JSON 形式で抽出して」「ニュース記事から人名・組織名・地名を抜き出して」「メール本文から日時・場所・参加者情報を構造化して」などがある。
6.3 翻訳・多言語変換
ある言語のテキストを別の言語に変換し、意味とニュアンスを保持するタスクだ。単なる逐語訳ではなく、文化的背景やビジネス慣習を踏まえた自然な表現への変換が求められる場合もある。
難易度は低〜中（言語ペアの難易度によって変動）で、文脈の保持やニュアンスの理解が必要だ。軽量〜中モデルで基本的には対応可能だが、専門用語が多い技術文書やニュアンスの再現が重要なマーケティング資料では中性能以上のモデルが推奨される。
具体例としては「この技術ドキュメントを日本語から英語に翻訳して」「顧客向けメールをビジネス的な丁寧さを保って中国語に訳して」「マーケティング資料を現地の文化に配慮してスペイン語に翻訳して」などがある。
6.4 フォーマット変換
データやドキュメントの形式を別の形式に機械的に変換するタスクだ。Markdown から HTML、JSON から YAML といった構造の対応づけが中心で、内容の解釈はほとんど必要ない。
難易度は低く、推論もほぼ不要（構造の変換とマッピングが主体）だ。軽量モデルで十分対応でき、単純な変換であれば API のコストや応答速度を重視してモデルを選ぶのが合理的だ。
具体例としては「この Markdown ファイルを HTML に変換して」「CSV 形式の顧客データを JSON 形式にして」「YAML 設定ファイルを TOML 形式に書き換えて」などがある。
6.5 画像からの文字抽出、音声からのディクテーション
画像内のテキストを読み取ってデジタルテキスト化する OCR（光学文字認識）や、音声を認識してテキストに書き起こすディクテーションのタスクだ。
難易度は低〜中で、認識処理が主体のため推論はほとんど必要ない。マルチモーダル（画像・音声を入力として扱える）対応モデルが必要だが、モデルの性能自体は中程度で十分だ。ただし、画質や音質に精度が大きく左右されるほか、専門用語が多い場合は認識精度が低下しやすい点に注意が必要だ。
具体例としては「手書きメモの写真をテキスト化して」「会議の録音から議事録を起こして」「スキャンした領収書から金額と日付を抽出して」などがある。
7. 分類・判定系
テキストやデータを事前に定義されたカテゴリに振り分けるタスク群だ。判定基準が明確なケースが多く、大量処理との相性が良い点が特徴だ。
7.1 分類・ラベリング（感情分析、モデレーション含む）
テキストやデータに対して、あらかじめ定義されたカテゴリのラベルを付与するタスクだ。顧客レビューの感情分析（ポジティブ／ネガティブ／中立の判定）や、コンテンツモデレーション（利用規約に違反しているかどうかの判定）もこのカテゴリに含まれる。
難易度は低〜中で、パターン認識や文脈理解といった最小限〜中レベルの推論で対応できる。軽量〜中モデルが適しており、大量データの一括処理に向いている。ファインチューニング（特定タスク用にモデルを追加学習させること）の効果が特に高い領域でもある。微妙なニュアンスの判断が求められる場合は中性能以上のモデルが望ましく、モデレーション用途では誤判定のリスクを考慮した運用設計が必要だ。
具体例としては「顧客レビューをポジティブ／ネガティブ／中立に分類して」「サポートチケットを問い合わせ種別ごとに振り分けて」「SNS 投稿が利用規約違反かどうか判定して」などがある。
8. 推論・問題解決系
複雑な論理問題や数学パズルなど、多段階の推論を重ねて解にたどり着くタスク群だ。LLM にとって最も難易度が高いカテゴリの一つだ。
8.1 推論・論理パズル
複数の条件や制約を同時に扱い、段階的な論理推論を積み重ねて正解を導くタスクだ。数学の証明問題、論理パズル、制約充足問題などが該当する。
難易度は高く、多段階の論理推論、制約条件の充足、演繹的推論といった最高レベルの推論能力が必要だ。Opus、GPT Pro などの高性能モデルの使用が強く推奨される。Chain-of-Thought（思考の連鎖）プロンプティング、つまりモデルに推論の過程を段階的に言語化させる手法が必須であり、途中の推論ステップを可視化させることで正答率と信頼性が大きく向上する。
具体例としては「5 人が異なる色の家に住んでいる。条件から誰がどの家に住むか推論して」「数独パズルを解いて、途中の論理ステップも示して」「『嘘つきと正直者』の論理パズルを解いて」などがある。