大言壮語なタイトルですが、大した内容じゃないです。
AIの使い方のいろは
初学者のための「仕組み・限界・頼み方・育て方」ガイド
対象：ChatGPT、Claude、Gemini、Copilot、Cursor、Codexなどを使い始めた人
目的：AIを「何でも知っている人」ではなく、資料・道具・確認工程を与えて仕事を進める協働者として扱えるようになること
情報基準日：2026年7月15日
0. 最初に結論
生成AIをうまく使うコツは、長くて巧妙な「呪文」を一発で当てることではありません。
大切なのは次の5点です。
- 目的を伝える — 何のために、誰が、どこで使うのか
- 材料を渡す — 最新情報、社内資料、前提条件、見本
- ルールを固定する — 禁止事項、判断基準、出力形式
- 途中で確認する — 調査・設計・作成・検証に分ける
- 結果を評価する — 正しさ、抜け漏れ、安全性、再現性を確認する
AIの性能が高くても、材料や評価基準が曖昧なら、もっともらしい誤答を返します。
逆に、目的・資料・ルール・道具・検証方法が揃えば、短い依頼でも高い品質を出しやすくなります。
AI活用の中心は、「上手な質問」から「AIが迷わず作業し、間違いに気づける仕組み」へ移っている。
1. そもそもAIとは何か
1-1. AIはひとつの技術名ではない
AI（Artificial Intelligence：人工知能）は、人間が行う認識・予測・判断・文章生成などを、コンピューターで実現する技術やサービスの総称です。
| 種類 | できること | 身近な例 |
|---|---|---|
| ルールベース | 決められた条件で判断する | 「温度が30度以上なら警告」 |
| 機械学習 | データから傾向を学び予測する | 迷惑メール判定、需要予測 |
| ディープラーニング | 多層のニューラルネットワークで複雑な特徴を学ぶ | 画像認識、音声認識、生成AI |
| 生成AI | 学習したパターンを使って文章・画像・音声・コードを生成する | ChatGPT、画像生成AI |
| AIエージェント | AIが道具を選び、複数手順を進める | Web調査、ファイル編集、テスト実行 |
「AI＝ディープラーニング」ではありません。
ただし、現在よく話題になる生成AIの多くはディープラーニングを基盤にしています。
1-2. ディープラーニングを平たく言うと
ディープラーニングは、大量のデータを見ながら、入力と出力の間にある複雑なパターンを多層のニューラルネットワークに学習させる方法です。
猫の画像を判定する場合、人間が「耳は三角、ひげがある」と全規則を書くのではなく、多数の例からモデル内部の数値を調整し、猫らしい特徴を捉えられるようにします。
ただし、AIが人間と同じ意味で理解していると断定するのは適切ではありません。実務では、次のように捉えると安全です。
大量のパターンを数値として圧縮し、入力に応じた有力な出力を計算する仕組み
ディープラーニングの発展については、LeCun、Bengio、Hintonによる2015年の総説が代表的な基礎資料です。
1-3. LLMは「文脈に続く内容を生成する巨大なモデル」
ChatGPTなどの中心にあるLLM（Large Language Model：大規模言語モデル）は、文章をトークンという小さな単位に分け、周囲の文脈から次に続きやすいトークンを計算します。
日本の首都は → 「東京」が続く可能性が高い
現在のLLMの多くは、2017年に発表されたTransformerという仕組みを基礎にしています。Transformerは文章内のどこに注目すべきかを計算しやすくし、大規模な学習と文脈処理を発展させました。
LLMは単なる暗記帳ではなく、膨大な文章から得た言語・概念・関係性のパターンを利用し、要約、翻訳、分類、比較、文章作成、コード生成、一定の推論などを行います。
ただし根本は、真実を必ず返すデータベースではなく、文脈に合う出力を生成するモデルです。
2. AIの回答は、どのように作られるのか
2-1. 「MVP」ではなく「もっとも適切そうな出力」
AIの回答原理をMVPと呼ぶのは一般的ではありません。製品開発でMVPは通常、Minimum Viable Product（実用最小限の製品）を指します。
生成AIの説明として近いのは、次の表現です。
入力された文脈、学習済みのパターン、設定、利用可能な資料や道具をもとに、適切そうな続きを確率的に生成する。
「確率が最大の一語だけ」を常に選ぶとは限りません。候補に揺らぎを持たせる設定もあるため、同じ質問でも回答が変わる場合があります。
2-2. 回答を作る5つの材料
学習済み能力
＋
現在の会話・添付資料
＋
システム・組織のルール
＋
検索・計算・DB・コードなどの道具
＋
生成後の検証
↓
最終的な応答結果
| 材料 | 内容 |
|---|---|
| 学習済みの能力・知識 | 言語、一般知識、文章構造、問題解決パターン |
| 現在の文脈 | 質問、会話履歴、貼付文章、添付ファイル |
| 上位ルール | 安全基準、権限、社内規程、出力制約 |
| 外部ツール | Web検索、API、DB、計算、コード実行、メールなど |
| 検証工程 | 引用確認、テスト、レビュー、人間承認 |
したがって、AIの品質はモデルの頭の良さだけでは決まりません。
品質 ≒ モデル能力 × 文脈の質 × 道具の質 × 作業手順 × 評価
2-3. AIの推論は演繹だけではない
AIの応答には次のような処理が混ざります。
- 演繹的：規則や条件から結論を出す
- 帰納的：複数の例から傾向を見つける
- 類推的：似た事例を手がかりに考える
- 確率的：複数候補から適切そうな出力を選ぶ
- 検索補助型：外部資料を根拠として組み立てる
- ツール実行型：計算、コード、DB照会などで確認する
AIは筋の通った説明を作れても、前提事実が誤っていることがあります。
そのため、論理の見た目と事実の正しさを分けて確認します。
2-4. 「もっともらしい」と「正しい」は別
LLMは文章の自然さを作るのが得意です。そのため、不明点を含んでいても、自信があるように説明することがあります。
特に確認が必要な情報は次のとおりです。
- 今日のニュース、価格、運行情報、法令、製品仕様
- 現在の役職者、料金、サービス機能
- 社内固有の手順、契約、設計、データ
- 医療・法律・金融・安全に関する判断
- 数値、日付、固有名詞、引用
- URL、論文名、製品機能の実在性
3. 最新情報を知るには何が必要か
3-1. 学習済み知識だけでは「今」を保証できない
モデルが新しくても、すべての最新情報を常に内部に保持しているわけではありません。現在の事実を扱う場合は、外部情報を取得して根拠にする必要があります。
3-2. Webスクレイピングだけが方法ではない
| 方法 | 説明 | 適した用途 |
|---|---|---|
| Web検索・ブラウジング | Webページを探して読み比べる | ニュース、一般調査 |
| Webスクレイピング | ページから情報を機械的に抽出する | 大量・定期収集 |
| API | 公式の窓口から構造化データを取得する | 天気、株価、製品情報 |
| RAG | 関連資料を検索し、回答材料として渡す | 社内規程、マニュアル |
| DB照会 | 業務データを直接検索する | 在庫、顧客、実績 |
| 人間確認 | 公式窓口や担当者に確認する | 責任の大きい判断 |
RAGは、学習済みモデルの内部知識だけで答えず、関連する外部資料を検索して回答に利用する考え方です。2020年のRAG論文では、モデル内部の知識と外部の検索可能な知識を組み合わせる方法が示されました。
初心者向けには、次の理解で十分です。
AIの記憶だけに頼らず、必要な資料を取りに行き、根拠を比較・整理してから答えさせる。
3-3. キュレーションの基本手順
- 調べたい論点を分ける
- 公式情報・一次資料を優先する
- 公開日と、出来事が起きた日を分ける
- 複数資料の一致点・相違点を整理する
- 事実と推測を分ける
- 出典を残す
- 人間が重要箇所を確認する
このテーマを最新情報で調査してください。
公式資料・一次情報を優先し、重要な主張には出典を付けてください。
公開日と出来事の日付を区別してください。
情報が食い違う場合は、各説と根拠を並べてください。
最後に「確定情報・有力な推測・不明点」を分けて整理してください。
4. プロンプトエンジニアリングは終わったのか
4-1. 終わってはいない。ただし単独では足りない
プロンプトエンジニアリングは、AIが要求に合う出力を返せるよう指示文を設計することです。現在も重要です。
ただし、複雑な仕事を一つの長大なプロンプトで解決する方法には限界があります。モデルが高性能化し、検索・コード実行・ファイル操作などを行えるようになった結果、重点は次の領域へ広がりました。
| 考え方 | 何を整えるか |
|---|---|
| Prompt Engineering | その場の指示 |
| Context Engineering | 必要な情報を必要な時に渡す仕組み |
| Workflow Engineering | 調査・設計・作成・検証の工程 |
| Tool Engineering | 検索、DB、コード、APIなどとの接続 |
| Rule / Skill Engineering | 再利用可能な規則・手順・専門知識 |
| Harness Engineering | 実行環境、権限、ログ、テスト、観測 |
| Eval Engineering | 合否基準、採点、回帰テスト |
| Loop Engineering | 作成→評価→修正の反復 |
つまり、プロンプトが消えたのではなく、大きな品質管理の仕組みの一部になったのです。
4-2. 発展の流れ
第1段階：質問応答
人間が質問し、AIが文章で答える。
課題：再現性が低い、最新情報を知らない、誤りを発見しにくい。
第2段階：プロンプトエンジニアリング
役割、目的、条件、例、形式を詳しく書く。
改善：形式や粒度を制御しやすい。
課題：長文化、更新負荷、一発回答への依存。
第3段階：RAG・ツール利用
AIが外部資料、検索、計算、コード、業務システムを利用する。
改善：最新情報や社内情報を根拠にできる。
第4段階：エージェントとワークフロー
AIが計画し、道具を使い、結果を見て次の行動を変える。
ReAct研究は、推論と外部への行動を交互に行うことで、知識源や環境から情報を得ながら問題を進める形を示しました。
第5段階：ルール・スキル・ハーネス・評価
手順をファイル化し、権限を限定し、ログ・テスト・評価を整える。
2025～2026年には、コンテキスト管理、Agent Skills、長時間稼働エージェントのハーネス、評価によるスキル改善などが、主要各社の公式技術資料でも前面に出ています。
4-3. なぜ一発プロンプトからループへ移ったのか
仕事は通常、次のように進むからです。
依頼
↓
前提確認
↓
資料収集
↓
方針設計
↓
試作
↓
評価
↓
修正 ─────┐
↓ │
完成判定 ←──┘
人間の仕事も一発で完成しません。AIにも途中成果、観測結果、テスト結果を返し、修正させた方が安定します。
5. 何を言語化・可視化すると、AIの答えが良くなるのか
5-1. AIが迷う原因は「能力不足」だけではない
AIが期待外れの答えを返す原因の多くは、次のどれかです。
- ゴールが複数あり、優先順位が不明
- 読み手や利用場面が不明
- 現状と理想が混ざっている
- 用語の意味が組織固有
- 判断基準が暗黙知
- 例外条件が書かれていない
- 元資料同士が矛盾している
- 完成の判定方法がない
- どこまで自動実行してよいか不明
これらを外に出すことが、AI活用における言語化・可視化です。
5-2. 最優先で言語化する12項目
| 項目 | AIに伝える内容 | ない場合に起きること |
|---|---|---|
| 1. 目的 | なぜ実施するか | 文章は正しいが役に立たない |
| 2. 利用者 | 誰が読む・使うか | 難易度や説明量がずれる |
| 3. 利用場面 | 会議、研修、実装、判断など | 出力形式が合わない |
| 4. 最終成果物 | 何を作れば完了か | 途中説明だけで終わる |
| 5. 現状 As-Is | 今どうなっているか | 実態と離れた一般論になる |
| 6. 目標 To-Be | どう変えたいか | 改善の方向が定まらない |
| 7. 制約 | 期限、予算、技術、規則 | 実現不能な提案になる |
| 8. 優先順位 | 品質、速度、費用、安全性の順 | トレードオフを誤る |
| 9. 判断基準 | 何を良い・悪いとするか | 好みで回答が揺れる |
| 10. 参考例 | 正解例、類似例、NG例 | 期待する粒度を推測する |
| 11. 例外・リスク | 通常外のケース、禁止事項 | 事故や抜け漏れが起きる |
| 12. 検証方法 | テスト、照合、承認方法 | 間違いに気づけない |
5-3. 最優先で可視化する8種類
文章だけで伝えにくい関係は、図や表にします。
| 可視化 | 何が分かるか | 適した表現 |
|---|---|---|
| 業務フロー | 誰が、いつ、何をするか | フローチャート、BPMN |
| システム構成 | 機能・DB・外部サービスの関係 | 構成図、C4、UML |
| データ構造 | 項目・主キー・関係 | ER図、データ辞書 |
| 状態遷移 | 何をきっかけに状態が変わるか | 状態遷移図 |
| 時系列 | いつ何が起きたか | タイムライン |
| 役割分担 | 誰が責任を持つか | RACI表 |
| 判断条件 | どの条件で分岐するか | 決定表、判断ツリー |
| 比較基準 | 候補を何で比べるか | 評価マトリクス |
原則：順序はフロー、関係は図、条件は表、定義は用語集、実物はサンプルで見せる。
5-4. AIが最適化しやすい「仕事の地図」
【目的】何のためか
↓
【成果物】何を完成させるか
↓
【利用者・場面】誰がどこで使うか
↓
【現状】今の業務・システム・課題
↓
【制約】守る条件、使える資源
↓
【判断基準】何を優先し、何を合格とするか
↓
【資料・事例】根拠と見本
↓
【工程】調査→設計→作成→検証
↓
【承認】誰が最終判断するか
5-5. 悪い依頼と良い依頼
悪い例
AIの研修資料を分かりやすく作って。
AIが推測しなければならないもの：
- 読者の職種
- 知識レベル
- ページ数
- 研修時間
- 会社のAI利用規程
- 何をできるようにするか
- 説明中心か演習中心か
- 合格基準
良い例
目的：
生成AIを初めて使う社員が、AIの限界を理解し、
社内情報を不用意に入力せず、根拠を確認しながら質問できるようにする。
対象：
PG・SE・PM・新人。AI用語はほぼ知らない。
利用場面：
60分の社内研修。講師が画面共有し、最後に10分の演習を行う。
成果物：
Markdown形式の講師用原稿。
全体は8章、各章に「要点・具体例・注意点・確認問題」を付ける。
必須内容：
AIの仕組み、学習済み知識と最新情報の違い、RAG・Web検索、
プロンプト、ルール、ツール、検証、情報漏えい対策。
制約：
専門用語には一行説明を付ける。
「AIは考えていない」など断定しすぎる表現は避ける。
社内固有情報は仮名にする。
品質基準：
高校生でも概要が分かる。
各章を3分以内で説明できる。
事実主張には公式資料または一次資料を付ける。
進め方：
まず章構成と不足情報を提示し、次に本文を作る。
最後に、抜け漏れ・誤解を生む表現・古い情報を自己点検する。
5-6. 曖昧さをなくすための具体質問
依頼前またはAIとの対話中に、次を埋めます。
- この成果物で、読み手に何を理解・判断・実行してほしいか
- 正解が複数ある場合、何を最優先にするか
- 絶対に変えてはいけないものは何か
- AIが推測してよい部分と、確認すべき部分はどこか
- 参考にすべき過去成果物は何か
- 失敗例・事故例・苦情はあるか
- 数字で測れる完成条件はあるか
- 誰が最終承認し、何を見て承認するか
6. AI作業カルテ：そのまま使えるMarkdownテンプレート
以下を案件ごとに保存すると、会話をまたいでも引き継ぎやすくなります。
# AI作業カルテ
## 1. 依頼の目的
- 背景：
- 解決したい問題：
- この作業で起こしたい変化：
## 2. 利用者と利用場面
- 利用者：
- 知識レベル：
- 利用場面：
- 利用環境：
## 3. 最終成果物
- 成果物：
- ファイル形式：
- 分量：
- 必須構成：
- 完了条件：
## 4. 現状（As-Is）
- 現在の流れ：
- 使用中のシステム：
- 関係者：
- 課題：
- 既知の例外：
## 5. 目標（To-Be）
- 理想の流れ：
- 改善したい指標：
- 変えないもの：
- 移行条件：
## 6. 制約
- 期限：
- 予算：
- 利用可能な技術・道具：
- 利用禁止：
- セキュリティ・法令：
- 人間承認が必要な操作：
## 7. 優先順位
1.
2.
3.
## 8. 判断基準
| 評価項目 | 合格条件 | 確認方法 |
|---|---|---|
| 正確性 | | |
| 網羅性 | | |
| 可読性 | | |
| 安全性 | | |
| 再現性 | | |
## 9. 用語集
| 用語 | この案件での意味 | 一般的な意味との差 |
|---|---|---|
## 10. 入力資料
| 資料名 | 役割 | 信頼度 | 基準日 | 優先度 |
|---|---|---|---|---|
## 11. 正解例・NG例
### 正解例
-
### NG例
-
## 12. 可視化
- 業務フロー：
- システム構成図：
- ER図：
- 状態遷移：
- 判断表：
- タイムライン：
## 13. 未決事項
| 論点 | 選択肢 | 仮置き | 確認者 |
|---|---|---|---|
## 14. 作業計画
1. 調査
2. 設計
3. 試作
4. 検証
5. 修正
6. 承認
## 15. 変更履歴
| 日付 | 変更内容 | 理由 | 決定者 |
|---|---|---|---|
7. AIとの付き合い方：実践テクニック
7-1. 質問は「役割」より「仕事の条件」を重視する
「あなたは優秀なコンサルタントです」だけでは品質は安定しません。
有効なのは次です。
目的 → 対象 → 材料 → 制約 → 判断基準 → 出力 → 検証
役割指定は補助として使います。
7-2. 一度に全部やらせない
複雑な依頼は工程を分けます。
第1回：論点と不足資料を洗い出す
第2回：資料を調査し、根拠表を作る
第3回：構成案を作る
第4回：本文を作る
第5回：反対意見・抜け漏れを点検する
第6回：完成条件に照らして修正する
ただし、単純な作業まで細分化すると遅くなります。失敗コストが高い作業ほど分割します。
7-3. 「質問して」だけでなく「仮定を明示して進めて」
質問ばかりで止まるAIも実務では使いにくいため、次のように指定します。
重大な曖昧さだけ質問してください。
軽微な不足は妥当な仮定を置いて進め、
最後に「置いた仮定」と「確認が必要な点」を一覧化してください。
7-4. 事実・解釈・提案を分けさせる
回答を次の3区分に分けてください。
1. 資料で確認できる事実
2. 事実から導いた解釈・推測
3. 推奨する対応
各項目に根拠または確認方法を付けてください。
7-5. 反証役を入れる
作成した案に対して、次の観点から反証してください。
- 前提の誤り
- 抜け漏れ
- 実行不能な条件
- セキュリティ上の問題
- 利用者が誤解する表現
- 別の有力な選択肢
その後、必要な修正版を提示してください。
7-6. 出力形式を固定する
Markdownの見出し、表、JSON、YAMLなど、後工程で扱いやすい形を指定します。
# 結論
# 根拠
# 未確定事項
# リスク
# 推奨アクション
# 出典
7-7. 会話をMarkdownに一時保管する
長い会話では、重要事項が埋もれたり、文脈上限を超えたりします。そこで節目ごとにMarkdownへ外部化します。
保存するもの：
- 目的と前提
- 決定事項
- 採用しなかった案と理由
- 用語定義
- 現在の成果物
- 未決事項
- 次の作業
- 参照資料
- 変更履歴
7-8. 蒸留は「短くすること」ではない
蒸留とは、会話を単に要約するのではなく、再利用に必要な情報を構造化して残すことです。
残す
- 決定と理由
- 制約
- 判断基準
- 例外
- 実例
- 未解決事項
- 根拠資料
削る
- 重複
- 雑談
- 既に棄却された案の細部
- 一時的な試行錯誤
- 根拠のない推測
蒸留依頼の例
ここまでの会話を、次回のAIが作業を再開できる引継書に蒸留してください。
単なる要約ではなく、次を分けてください。
- 目的
- 決定事項と理由
- 固定ルール
- 用語集
- 入力資料
- 現在の成果物
- 未決事項
- リスク
- 次の具体的作業
- 棄却案と棄却理由
推測で補完せず、不明点は不明と明記してください。
7-9. 元資料とAI生成物を分ける
推奨ディレクトリ例：
project/
├─ 00_source/ # 原本。原則変更しない
├─ 01_context/ # 用語集、前提、作業カルテ
├─ 02_research/ # 調査結果、出典一覧
├─ 03_design/ # 方針、構成、ADR
├─ 04_working/ # AIの途中成果
├─ 05_review/ # テスト、レビュー、指摘
├─ 06_output/ # 承認済み成果物
└─ CHANGELOG.md
AIが何を根拠に、何を変更したか追いやすくなります。
8. 仕事別の具体例
8-1. 文書作成
言語化するもの：
- 読者
- 読後に取ってほしい行動
- 重要メッセージ
- トーン
- 必須項目
- 禁止表現
- 根拠資料
- 分量
可視化するとよいもの：
- 文書構成
- 読者の疑問の順序
- 主張と根拠の対応表
8-2. システム開発
言語化するもの：
- ユースケース
- 機能要件・非機能要件
- 技術制約
- 受入条件
- エラー時の挙動
- 権限
- 変更対象外
可視化するとよいもの：
- 画面遷移
- シーケンス図
- ER図
- API仕様
- 状態遷移
- システム構成
- テスト対応表
「ログイン機能を作って」より、画面・API・DB・権限・異常系・テスト条件が揃った方が実装品質は大きく上がります。
8-3. 業務改善
言語化するもの：
- 現行業務の目的
- 問題と発生頻度
- 担当者ごとの責任
- 判断に使う情報
- 例外処理
- 改善後のKPI
可視化するとよいもの：
- As-Is / To-Beフロー
- RACI
- 工数・待ち時間
- 課題と原因の関係
- システム・帳票・データの対応
8-4. 調査・比較
言語化するもの：
- 調査目的
- 比較候補
- 評価軸
- 基準日
- 対象地域
- 予算
- 公式情報の優先度
- 推測を許す範囲
可視化するとよいもの：
- 比較表
- 根拠マトリクス
- メリット・デメリット
- 確定／推測／不明の区分
- 出典と主張の対応表
9. AIを使うときの安全ルール
9-1. 入力してよい情報か確認する
- 顧客情報
- 個人情報
- 認証情報
- APIキー
- 契約書
- 未公開ソースコード
- 社外秘資料
- 障害ログ
- 医療・人事情報
利用プラン、契約、保存設定、学習利用の有無だけでなく、会社の規程とアクセス権を確認します。
9-2. AIに与える権限は最小限にする
文章案を作る権限と、実際にメール送信・ファイル削除・本番反映する権限は別です。
低リスク：読む、要約、下書き
中リスク：ファイル編集、コード修正、予定作成
高リスク：送信、削除、本番反映、支払い、権限変更
高リスク操作には人間承認、ログ、ロールバック手段を設けます。
9-3. AIの出力は「下書き」か「検証済み」かを明示する
- Draft：未確認
- Reviewed：人間または別工程で確認済み
- Approved：責任者承認済み
- Published / Deployed：公開・反映済み
状態を混ぜないことが重要です。
10. 初心者が今日から使える基本形
10-1. 万能ではないが失敗しにくい依頼テンプレート
【目的】
何のために行うか：
【対象】
誰が読む・使うか：
知識レベル：
【成果物】
何を作るか：
形式・分量：
【前提・材料】
参照する資料：
現在の状況：
用語の定義：
【制約】
期限・予算・禁止事項：
推測してよい範囲：
人間確認が必要な箇所：
【優先順位】
1.
2.
3.
【品質基準】
正確性：
網羅性：
読みやすさ：
安全性：
完成条件：
【進め方】
必要なら、調査→設計→作成→検証に分けてください。
重大な不明点は質問し、軽微な点は仮定を明示して進めてください。
【出力】
結論、根拠、未確定事項、リスク、次の行動を分けてください。
10-2. AI自身に依頼文を点検させる
この依頼を実行する前に、AIが推測せざるを得ない部分を抽出してください。
各項目を次の3段階に分類してください。
A：不足すると結果が大きく変わるため、確認が必要
B：妥当な仮定を置いて進められる
C：出力後に調整できる
その後、Aだけ質問し、Bは仮定を明示して作業してください。
10-3. 完成後の自己点検
成果物を次の観点で採点してください。各5点満点です。
- 目的への適合
- 事実の正確性
- 根拠の追跡可能性
- 抜け漏れ
- 初心者への分かりやすさ
- 制約遵守
- 安全性
- 実行可能性
3点以下の項目は、問題点と修正版を提示してください。
確認できない内容は、確認済みのように扱わないでください。
11. よくある誤解
| 誤解 | 実際 |
|---|---|
| AIは何でも知っている | 学習済み知識・現在の文脈・利用可能な道具の範囲で答える |
| 自然な文章なら正しい | 自然さと事実性は別 |
| 長いプロンプトほど良い | 関係ない情報は重要事項を埋もれさせる |
| 最新モデルなら確認不要 | 最新情報、数値、固有名詞は確認が必要 |
| AIに考えさせれば要件定義も不要 | 暗黙知を推測させるほど結果が揺れる |
| Web検索すれば必ず正しい | 情報源の品質、日付、矛盾の確認が必要 |
| AIエージェントなら自律的に任せられる | 権限、停止条件、ログ、評価、人間承認が必要 |
| プロンプトエンジニアリングは不要 | 指示は必要。ただし文脈・道具・工程・評価と一体で設計する |
| 蒸留は短い要約のこと | 決定理由・制約・例外・未決事項を再利用可能に構造化すること |
12. まとめ
AIは魔法の答え箱ではありません。
AIが得意なのは、渡された文脈からパターンを読み取り、文章・案・分析・コードなどの候補を高速に生成することです。
AIから良い結果を得るために、人間が担うべき役割は次のとおりです。
- 目的を決める
- 現状と理想を言語化する
- 関係や条件を図表で見せる
- 根拠資料を渡す
- 優先順位と判断基準を示す
- 道具と権限を適切に与える
- 途中結果を観測する
- 合否を評価する
- 最終責任を持つ
AIに最適な答えを出させるには、答えそのものを教える必要はない。
何を目指し、何を根拠に、何を守り、どう合否を決めるかを見える形にする。
参考資料
-
Yann LeCun, Yoshua Bengio, Geoffrey Hinton, “Deep learning,” Nature, 2015
https://www.nature.com/articles/nature14539 -
Ashish Vaswani et al., “Attention Is All You Need,” 2017
https://arxiv.org/abs/1706.03762 -
Patrick Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” 2020
https://arxiv.org/abs/2005.11401 -
Shunyu Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models,” 2022
https://arxiv.org/abs/2210.03629 -
OpenAI, “Prompt engineering / Prompting”
https://developers.openai.com/api/docs/guides/prompt-engineering
https://developers.openai.com/api/docs/guides/prompting -
OpenAI, “Harness engineering: leveraging Codex in an agent-first world,” 2026
https://openai.com/index/harness-engineering/ -
OpenAI, “Testing Agent Skills Systematically with Evals,” 2026
https://developers.openai.com/blog/eval-skills -
Anthropic, “Building effective agents,” 2024
https://www.anthropic.com/engineering/building-effective-agents -
Anthropic, “Effective context engineering for AI agents,” 2025
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents -
Anthropic, “Equipping agents for the real world with Agent Skills,” 2025
https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills -
Anthropic, “Effective harnesses for long-running agents,” 2025
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
注記
- 本資料は、初心者向けに技術概念を簡略化しています。
- 「AIが理解する」「考える」などの日常語は、内部処理が人間と同じであることを意味しません。
- サービス仕様、料金、保存方針、機能、法令は変わるため、利用時点の公式情報を確認してください。