本書は、同志社大学大学院「AIビジネス実践論」第4回の副教材です。講義を受けていない人も、AIに渡す背景、仕事の順番、結果の確かめ方を学び、自分の一作業の設計図を作れるように構成しています。

対象は、専門領域やAIの利用経験が異なる大学院生です。プログラミングの知識は前提にしません。AIを使った経験がある人は、現在の使い方を一つ改善するために読んでください。

講義日：2026年10月28日／教材の基準日：2026年10月24日。

本書では、講師向けの制作指示書「第04回_プレゼンテーションコンテキスト.md」を「講義準備資料」と呼びます。一方、計算や主張の根拠となる財務諸表・論文などは「原資料」と呼び、区別します。

本書の使い方と、最初に守ること

学ぶのは「うまいプロンプトの書き方」よりも仕事の設計

「AIに上手に質問できるようになりたい」と考えると、便利なプロンプト(指示文)を探したくなるかもしれません。しかし、指示文だけでは解決できない問題があります。

例えば、「売上を伸ばす案を考えて」と頼んで、値引きの提案が返ってきたとします。自分の店では値引きをしないと決めているなら、その提案は使えません。文章が自然か、アイデアが面白いかという評価より前に、店の事情が伝わっていない可能性を考える必要があります。

また、値引きをしない案が返ってきても、それだけで売上が伸びるとは限りません。実施するための人手があるか、顧客への案内が許可されているか、実施後に何を測るかも別に考えます。

本書では、AIとの仕事を次の問いで捉えます。

問い	考える内容
何のために、何を作るか	目的・成果物・合格条件
AIに何を伝えるか	必要な背景、不足する情報、渡せない情報
どの順番で進めるか	工程、途中の確認、停止、差し戻し
何を根拠に使うか	原資料、計算、現場の手順、専門家への確認
次に何を変えるか	試行の記録と、自分の学び

これは、本講義で使う整理の仕方です。あらゆるAI利用の成功を保証する法則や、能力を測る検証済みの尺度ではありません。

読む順番と、学習後にできること

前半では、AIが答えを返すことと、ツールを使って仕事を進めることの違いを学びます。中盤では、同じ架空のお店の例を使って、背景の整理から提案の採否までを追います。後半では、自分の研究や仕事に置き換えて設計します。

学習のまとまり	主な内容	学習後に説明すること
第1〜2章	AI・Skill・ツールの役割と三つの事例	AIがどこで何をし、人が何を確認するか
第3〜5章	目的、背景情報、質問による依頼文づくり	何が分かり、何が分からず、何を渡せないか
第6〜8章	工程、停止・差し戻し、専門的な検証	次へ進む条件と、採用の根拠
第9〜10章	学び方とMicrosoftの公開例	製品の機能紹介と、自分の判断の関係
第11〜12章	演習と自分の一作業の設計	別の題材でも設計を具体化できるか
第13〜16章	よくある疑問、解答、用語、出典と未確認範囲	必要に応じて参照し、判断の根拠と限界を確認する

第11章の問題は、先に自分で考えてから第14章の解答・解説を読んでください。演習はすべて授業後の自習用であり、講義中の端末操作や記入を求めるものではありません。

AIを使わずに学ぶ方法もある

本書の対話例は、実際のAIの回答を収録したログではなく、考え方を説明するための教材例です。AIを利用できなくても、対話例を読み、依頼文や設計図を紙・メモアプリに書くことで学べます。

新しいアカウントや有料契約は必要ありません。AIを利用する場合は、大学・所属組織・研究室などのルールと、利用サービスの条件を先に確認してください。利用が認められていない作業では、AIへの入力やツールの実行をせず、設計と確認先の整理までにします。

実際の個人情報、未公開の研究内容、顧客情報、秘密保持義務のある資料を、練習のために入力してはいけません。最初は公開情報や架空の条件を使いましょう。公開されている資料でも、転載やAIへの入力が無条件に許されるとは限りません。

本書は授業関係者向けのローカル文書です。冒頭の private: true はQiita形式の設定であり、このファイルや、将来の共有先へのアクセスを制限する仕組みではありません。

第1章　答えるAIと、仕事を進めるAIの違い

1.1　文章を作ることと、現実を確かめることは違う

生成AIは、文章などを生成するAIです。本書で扱う対話型AIの多くは、大量の言語データなどから学習したモデルを使い、入力に応じて回答を作ります。ここで重要なのは、自然な文章を作れることと、その内容を確認できていることは別だという点です。

例えば、AIが「この店には既存顧客向けのメールが有効です」と答えても、その店の顧客がメールの受信に同意しているか、配信できる仕組みがあるかまで調べたとは限りません。AIが、その店の事情を知っているとも限りません。

実在する資料の名称や数値が書かれていても同様です。出典が本当に存在するか、該当箇所に主張を支える記述があるかを確かめる必要があります。もっともらしく説明できることを、根拠の確認が終わったことと取り違えない ようにしましょう。

1.2　仕事は、入力と成果物をつなぐ複数の工程からできている

「論文の比較表を作る」という仕事を考えます。文章を生成するだけでなく、比較する論文を決め、本文を読み、測定条件をそろえ、出典を付け、比較できない部分を区別する必要があります。

このとき、一つの依頼の中には、異なる種類の処理が含まれています。

目的と比較基準を決める
        ↓
利用できる論文を集める
        ↓
条件と結果を抽出する
        ↓
比較可能性を確認する
        ↓
比較表と、比較できない理由をまとめる
        ↓
原論文と照合して採否を決める

AIに文章案を作ってもらうだけでなく、検索や計算などのツールを使わせ、途中の結果を次の工程へ渡すと、仕事の進め方そのものを支援できます。ただし、必要なツール、権限、入力資料がそろっていなければ、その工程は実行できません。

1.3　AIエージェント・Skill・ツールを分けて理解する

本書では、目的に向けて処理を選び、必要に応じてツールを使い、結果を受けて次の処理へ進む仕組みを、AIエージェントとして説明します。実際にできることや、人の確認が必要な範囲はシステムごとに異なります。「エージェント」という名前だけで、全自動で完了するとは判断できません。

仕事を進める仕組みを見るときは、次の役割を分けると理解しやすくなります。

要素	本書での意味	論文比較の例
AIモデル	入力を解釈し、文章や処理案などを生成する部分	比較項目を提案し、抽出結果を説明する
AIエージェント	AIモデルと工程・ツールなどを組み合わせて仕事を進める仕組み	検索、抽出、表の作成をつなぐ
Skill	仕事の進め方や確認基準などを再利用できる形でまとめたもの	論文を比較するときの手順と注意点
外部ツール	検索・計算・ファイル処理などを実行する仕組み	検索システム、計算環境、文書作成ツール
人の判断	目的、利用範囲、成果物の採否などを決めること	比較対象が適切かを判断し、表の使用を決める

Skillは、人の技能やAIモデルの学習済み知識と同じものではありません。また、すべての製品で形式や呼び方が共通しているわけでもありません。本書では、講義で紹介する「仕事の手順や基準を与える仕組み」という意味で使います。

Skillに「計算結果を確認する」と書くことと、計算を実行できるツールが接続されていることも別です。手順があっても、必要な資料にアクセスできない、権限がない、ツールが失敗した、ということは起こります。

1.4　ハーネスエンジニアリングは、AIが動く周囲の仕組みを設計すること

AIに使わせるツールや実行環境、権限、仕事の手順、確認方法なども、設計の対象です。本書では、これらを整える設計をハーネスエンジニアリングの考え方として紹介します。

例えば、「計算を間違えないで」と頼むだけでなく、計算ツールを使えるようにし、入力値と計算結果を記録し、失敗したら止まるようにする設計です。どの計算をするかをAIが提案できても、実行する場所や、結果を採用する基準は別に必要です。

仕事の手順・確認基準
          ↓
AIが処理を選ぶ
          ↓
許可されたツールで実行する
          ↓
結果またはエラーを受け取る
          ↓
確認し、説明する／修正する／止める

これは、「高度な指示文さえあれば何でもできる」という発想とは異なります。文章による指示だけでなく、実際の接続や権限の設定も含めて考えます。

第2章　三つの事例から、仕事の構造を読み取る

2.1　授業設計――AIの案を、学ぶ人に合わせて見直す

この講義の準備も、AIを使う仕事の例です。講師が参考にしているのは、前の講義の内容、受講生のフィードバックを集約した情報、Microsoftの公開情報などです。これらを基に、今回の内容や順番を検討しています。

講師が使用を説明したのは、自ら開発している技術文書作成支援のAIエージェント「kotonoha（ことのは）」です。

講師は、授業設計専用のSkillを持っていたわけではありません。講師自身が工程を分け、一段階ずつ必要な情報と確認事項を指示しています。

ここでは、次の役割分担に注目してください。

工程	AIが支援すること	講師が判断すること
学習課題の整理	既習内容や残る問いを整理する	整理が資料に基づいているか
構成の検討	内容と説明順序を提案する	受講生の経験の幅に合うか
シナリオ案の作成	話す内容を文章にする	学習目標と内容がつながっているか
点検と修正	指摘に応じて説明や順序を直す	情報量、根拠、学ぶ人への適合性

「教育工学の観点で点検する」とは、例えば、学んでほしいことと説明内容が対応しているか、既に学んだことから無理なく進めるかを見直すことです。点検したという事実と、学習効果が測定されたという主張は別です。

また、シラバスの本文は、講義準備資料での確認時点では未取得でした。授業を設計するときの重要な入力候補ではありますが、「正式なシラバスの内容を確認済み」とは扱えません。必要な情報を、あることにして進めないという例でもあります。

2.2　教材制作――前の成果物が次の入力になる

授業シナリオができても、音声付きの教材が完成したわけではありません。シナリオをスライドにし、各スライドのノートに台本を入れ、その台本から音声を作る、といった工程があります。

講師が説明した制作工程では、PPTXのノートから台本を取り出し、Azure Speechへ渡して音声を生成し、音声をPPTXへ埋め込みます。その後、音声の自動開始とスライドの自動切り替えを設定します。

台本の抽出、受け渡し、音声の埋め込み・再生設定には、講師の説明上「Microsoft Scout」という名称のツールが登場します。ただし、本書ではその提供区分や製品仕様、実際の再生動作を確認していません。初期PPTXを生成する担当ツールも、講義準備資料では指定されていません。一般に利用できる公式の標準手順として紹介するものではありません。

この例で注目するのは、製品名ではなく、成果物の受け渡しです。

授業シナリオ
    ↓ スライドにする
ノートに台本を含むPPTX
    ↓ 台本を抽出する
音声生成に使う文章
    ↓ 音声を生成する
音声データ
    ↓ 埋め込み・再生設定をする
音声付きPPTX

途中の台本に誤りがあれば、自然な音声になっても誤りは残ります。工程をつなぐ設計では、「渡せる形式か」だけでなく、「次へ渡してよい内容か」を確認する必要があります。

2.3　AIRA――論文から研究計画案へ進む

AIRA（アイラ）は、講師個人が開発している研究支援AIです。Microsoftの公式製品ではありません。講師の説明では、自然言語の指示を受け、研究情報の収集や実験計画などの案づくりを支援します。

講義の題材は、新しいペロブスカイト太陽電池を探すための研究計画です。ペロブスカイト太陽電池とは、特定の結晶構造を持つ材料を使う太陽電池です。本書では材料の専門知識より、研究情報から計画案を作る工程を見ます。

関連論文を検索・収集する
        ↓
材料・条件・結果の関係を知識グラフに整理する
        ↓
知見と、研究の空白領域の候補を探す
        ↓
次に調べる方針と研究計画案をまとめる

知識グラフは、情報どうしの関係を整理したものです。例えば、ある材料をどの条件で測定し、どのような結果を得たかという関係を、元の論文へ戻れる形で整理することが考えられます。この説明は形式を理解するための例であり、特定の論文から抽出した実データではありません。

関係を整理できれば、複数の論文を横断して考える助けになります。ただし、抽出の際に条件を落としたり、結果を取り違えたりすれば、整理された図自体が誤る可能性があります。重要な関係は、論文の該当箇所に戻って確かめます。

また、グラフに関係が見つからないことは、世界で研究されていないことの証明ではありません。検索対象外の論文がある、本文を取得できていない、抽出に失敗した、といった可能性があります。

「収集した論文の範囲では見つからない」と「誰も研究していない」は、異なる主張です。

研究計画案を作ることと、実験を実施して性能を確かめることも別です。この講義で説明する仮説の探索・評価は、論文や知識グラフを使った検討であり、実機実験の実施や新材料の発見を実証したものではありません。

2.4　探索は、続け方だけでなく止め方も設計する

研究では、案を出し続ければ必ず前進するわけではありません。同じ仮説を何度も検討したり、似た案に偏ったり、反対の証拠を見落としたりすることがあります。

講師が説明するAIRAの探索制御には、次の六つの考え方があります。これは機能の説明であり、順番に一度ずつ実行する固定手順ではありません。

考え方	避けたい問題	判断するときの注意
探索した仮説を記録する	同じ検討を理由なく繰り返す	新しい根拠がある再評価とは区別する
仮説間の類似度を見る	表現だけ違う似た案に偏る	何を似ていると扱うかを決める
停滞したら戦略を変える	同じ方法で進展のない試行を続ける	何を改善・停滞と判定するかを決める
活用と探索の配分を考える	有望な領域だけ、または未知の領域だけに偏る	目的と残りの資源に応じて配分する
反証を調べる	自分の仮説に都合のよい根拠だけ集める	成立しない条件や反対の証拠も見る
停止条件を設ける	循環や無制限の再試行が続く	上限に達したら停止を優先する

「活用」は既に有望と見られる領域を深めること、「探索」はまだよく分からない領域を調べることです。講師の説明には、この配分の調整にベイズ最適化などを使う考え方が含まれます。ベイズ最適化は、得られた観測を基に、次に試す候補を選ぶ最適化手法です。ここでは数式や実装方法までは扱いません。

試行回数・時間・予算の上限は、停止条件の例です。AIRAに実際に設定された値を示しているわけではありません。停止条件に達しているのに、戦略変更を理由に試行を延々と続けないことが重要です。

本書では、六つの機能の実装・作動、類似度や停滞の判定方式、ベイズ最適化の適用箇所を検証していません。実際のシステムの性能評価ではなく、探索を設計する際の論点として学んでください。

2.5　Jupytermind――AIの説明から、実行した計算へ戻る

Jupytermind（ジュパイターマインド）は、講師が開発している分析支援の事例です。講義では、国立大学病院の公開財務資料を使った保存済みの分析結果を紹介します。

Jupyterは、コードを実行し、結果とともに記録できる外部ツールです。処理をひとまとまりずつ記述したNotebookには、コード、説明文、表やグラフなどの出力を残せます。

この事例の仕組みは、次のように説明されています。

Skill：分析の進め方と確認基準
                 ↓
AI：分析用のコードを作る
                 ↓
Jupyter：コードを実行する
                 ↓
AI：返ってきた結果を受けて説明する
                 ↓
人：公開原資料・計算・説明の対応を確認する

重要なのは、AIが数字らしい文章を作るだけでなく、計算をツールへ渡し、その結果を受けて説明することです。目的のために外部ツールを使い、実行環境や確認方法まで整える点で、ハーネスエンジニアリングの考え方につながります。

ただし、保存済みのコードと出力があることだけで、AIによる全自律操作の履歴が確認できるわけではありません。また、コードが実行できても、入力した列や集計方法が正しいとは限りません。

一つの計算を、説明から元値へたどる

講義準備資料では、浜松医科大学医学部附属病院の2025年度の業務損益率を、計算根拠へ戻る例にしています。全国の代表例や優良な経営の例として選ばれたものではありません。

以下は、講義の準備資料に記録された値です。本書作成時に、公開サイトの訂正版や全資料を改めて照合したものではありません。

項目	財務諸表の単位による値	百万円に換算した値
業務収益	36,744,306千円	36,744.306百万円
業務損益	596,574千円	596.574百万円

業務損益率は、次の算式です。

業務損益率（%）＝ 100 × 業務損益 ÷ 業務収益
100 × 596,574 ÷ 36,744,306 ≒ 1.62%

分子と分母を同じ単位でそろえれば、千円の値でも百万円の値でも同じ率になります。一方、対象の異なる列を使えば、計算自体はできても別の意味の数字になります。病院の指標を計算するのに、法人全体の合計列を分母にしてはいけません。

この計算で分かるのは、定義した範囲の業務収益に対する業務損益の割合です。診療の質、患者への価値、経営の優劣、損益が変化した原因までを、この一つの率から断定することはできません。

講義で紹介する分析は財務比較の初版で、2025年度の比較に採用したのは対象42本院のうち34本院です。採用できなかった本院の値をゼロと見なしたり、採用した34本院の結果を全国42本院すべての結果として説明したりしないようにします。

2.6　事例が違っても、確認する構造は共通する

題材	作りたい成果物	必要な背景の例	主な確認先
授業設計	授業シナリオ	到達目標、既習内容、受講生の経験	授業資料、講師の判断
研究探索	研究計画案	論文、測定条件、検索した範囲	原論文、研究者の検討
財務分析	分析メモ	年度、単位、会計上の対象範囲	公開原資料、計算コード、出力

三つの事例から学ぶのは、「AIならどの仕事も任せられる」という結論ではありません。目的、入力、工程、検証をつなぎ、できたことと確かめていないことを分ける見方です。

第3章　目的・成果物・合格条件を分ける

3.1　目的は、何を実現したいか

目的は、仕事をする理由です。「売上を伸ばしたい」「研究の方向を決めたい」「初めて学ぶ人に内容を理解してもらいたい」などが当たります。

ただし、目的の表現が大きいままだと、今AIに何をしてもらうかが決まりません。「売上を伸ばしたい」から直ちに施策を実施するのではなく、まず施策案を作る、という一作業に分けることができます。

目的は途中で見直しても構いません。対話の結果、「新規客を増やしたいのではなく、既存客の再購入を増やしたい」と分かれば、より具体的な目的へ修正します。

3.2　成果物は、今回作るもの

成果物は、作業の終わりに受け取る具体的なものです。「提案書」「比較表」「確認事項の一覧」など、何を受け取れば今回の作業が終わるかを表します。

同じ目的でも、成果物は異なります。例えば「研究の方向を決めたい」に対して、論文の一覧、論点の比較表、追加調査の計画案では必要な作業が違います。

大きな目的	今回の一作業	今回は実施しないこと
既存顧客の再購入を増やす	条件に合う施策案を作る	顧客への送信、店舗での実施
研究の方向を検討する	論文の比較表を作る	新規性の断定、実機実験
発表を分かりやすくする	聴衆に合う構成案を作る	スライドの公開、内容の無確認での使用

「今回はしないこと」を決めると、AIに案づくりを頼む範囲と、現実に行動する範囲を分けやすくなります。

3.3　合格条件は、次へ渡してよいかを決める基準

合格条件は、「よい感じ」ではなく、成果物を見て判断できる条件にします。お店の施策案なら、次のように書けます。

既存顧客の再購入を目的とする案である。
値引きを前提にしていない。
担当者一人で実施できるかを検討するため、必要な作業を示す。
作業量など未確認の条件は、未確認と明記する。
条件への適合と、売上効果の予測を区別する。

ここで「一人で実施できる」と確認済みにするには、担当者の使える時間や実際の手順を調べる必要があります。提案書に「一人でできます」と書かれているだけでは、合格の根拠になりません。

また、案の合格条件と、施策の効果を測る条件は別です。条件を満たす提案ができることは、実施後に成果が出ることを保証しません。

第4章　コンテキストは、AIにまだ伝えていない背景を言葉にすること

4.1　自分には当たり前でも、AIには伝わっていない

本講義では、コンテキストを「AIが知らない背景情報を言語化すること」から説明します。例えば、「この資料は初めて学ぶ人向け」「前の提案は予算の都合で採用できなかった」「今回は値引きしない」といった事情です。

より広く、AIが仕事に取り組む際の情報やその与え方を設計する考え方を、コンテキストエンジニアリングとして扱います。本書では、その入口となる背景の言語化と選択に焦点を当てます。

AIが一般的な知識を持っていても、今回の依頼者だけが知っている事情まで共有されているとは限りません。過去の会話に書いたことも、今回の作業で確実に参照されるかは、利用する仕組みによって異なります。

例えば「説明資料を作って」という依頼に、次の背景を加えると、選ぶべき内容が変わります。

背景の種類	伝える内容の例	内容を変える理由
相手	専門用語を初めて学ぶ人向け	用語説明が必要になる
経緯	前回、具体例が足りないと言われた	例を増やす必要がある
制約	機密情報は載せない	使える資料と表現が限定される
利用場面	読み返せる配布資料にする	口頭説明なしでも理解できる必要がある

役職や専門家の役割をAIに指定するだけでは、こうした個別事情は埋まりません。「優秀な経営者として考えて」と書くより先に、今回の店の条件を伝える必要があります。

4.2　同じ依頼に、必要な背景を加える

ここから使うお店は架空です。実在の店舗や顧客の情報、実際のAIの回答を示すものではありません。

最初の依頼は、次の一文です。

売上を伸ばす施策を考えてください。

この依頼からは、店が優先したいことも、できないことも分かりません。そこで、今回の判断に関わる三つの事情を加えます。

既存顧客の再購入を増やしたいと考えています。
値引きはしません。
担当者一人で実施したいと考えています。

これで、少なくとも「新規客向けの値引きキャンペーンをそのまま採用する」といった判断は避けやすくなります。ただし、商品、使える時間、予算、案内手段などが分かったわけではありません。

三つの背景は、説明のために選んだものです。この三点だけで、常に十分な提案ができるという意味ではありません。今回の成果物を作るために、何を追加で確認すべきかを考えます。

4.3　情報は「必要性」と「利用できるか」を分けて整理する

資料をたくさん渡すほどよい、とは限りません。関係の薄い情報が増えると、重要な条件が見えにくくなる場合があります。古い条件と新しい条件を混ぜれば、どちらを優先すべきかも曖昧になります。

まず、その情報が今回の判断に必要かを考えます。そのうえで、必要な情報の扱いを次のように整理します。

情報の状態	お店の例	扱い方
必要で、既にあり、利用できる	値引きをしないという確認済みの方針	現在の条件として伝える
必要だが、まだない・確認できていない	担当者の使える時間	確認先を決め、未確認と明記する
必要でも、利用条件上渡せない	入力が許可されていない顧客記録	入力せず、代替情報や別の進め方を検討する

利用不可の情報は、手元にある場合も、ない場合もあります。この整理は厳密な排他的分類というより、必要性、不足、利用可否を見落とさないための実務上の見方です。

今回の目的に関係しない資料は、三つの状態に無理に入れず、渡す対象から外します。情報の量を増やすことより、何の判断に必要なのかを説明できること が重要です。

4.4　不明なことは、不明なまま共有する

「予算はまだ決まっていません」と答えることは、対話の失敗ではありません。分からないのに数字を作るより、判断の範囲を正しく限定できます。

例えば、次のように伝えます。

担当者が使える時間は、まだ確認できていません。
一人で実施できるとは断定しないでください。
案には、必要な作業と、実施前に確認すべきことを示してください。

仮定を置いて案を比べることはできます。ただし、「仮に使える時間がこの程度なら」という検討用の仮定と、確認済みの事実を混ぜないようにします。

不明な情報が成果物の採否に不可欠なら、その判断は保留します。一方、確認事項の一覧を作るところまでなら進められる場合があります。「何も分からないから何もできない」と「分からないまま採用してよい」の二択ではありません。

4.5　情報を渡す前の点検

点検する問い	曖昧なときの対応
この情報で、どの判断が変わるか	目的との関係を見直す
どの時点・範囲の情報か	日付、対象、定義を確認する
事実か、希望か、仮定か	状態を分けて書く
AIへ入力する許可があるか	利用ルールや資料の条件を確認する
別の情報で目的を満たせるか	許可された集計情報や架空例を検討する

氏名を消しただけで、安全に共有できるとは限りません。所属や研究テーマ、少数の属性の組み合わせから本人が分かることもあります。自分だけの判断で「匿名化したからよい」と決めず、必要な許可と扱い方を確認してください。

第5章　足りない背景をAIに質問してもらう――メタプロンプト生成法

5.1　足りない情報を、最初から全部思い付く必要はない

背景を伝える必要があると分かっても、何が必要なのかを自分だけで洗い出すのは難しいものです。特に、初めて取り組む仕事では、確認項目そのものが分かりません。

そこで、AIに不足情報を考えてもらい、一問ずつ質問してもらいます。回答を重ねた後、そのやり取りを踏まえた依頼文を生成してもらう方法です。

本講義では、これを「メタプロンプト生成法」と呼びます。プロンプトはAIへの指示や入力であり、ここでのメタプロンプトは、目的に合うプロンプトを作るための指示です。メタプロンプトという語にはほかの使い方もあり、本書の方法だけを指す用語ではありません。

5.2　まず、この提示文と自分の目的を伝える

講義で紹介する提示文は、次のとおりです。

これから私の目的を伝えます。
目的を達成するために足りない情報があれば、私に１問ずつ聞いてください。
すべての情報がそろったら、目的を達成するために最適なプロンプトをあなたが生成してください。

この文章に続けて、自分の目的を伝えます。

私の目的は、店の売上を伸ばす施策を考えることです。

「すべての情報」「最適」は、AIに対する依頼の表現です。AIが不足を漏れなく発見することや、生成した依頼文が最適であることを保証する言葉ではありません。

また、この提示文が指示しているのは、依頼文の生成までです。その依頼文を使うか、提案を作るか、現実の作業を実施するかは、それぞれ後の段階で判断します。

5.3　一問ずつの対話を、具体的に追う

次の対話は、仕組みを学ぶために作った架空例です。商品や作業量などを実際に調べた結果ではありません。質問の数と順番は固定ではなく、利用するAIによって変わります。

最初の質問：狙いを具体化する

AI：

新しいお客さまと、今のお客さまの再購入では、
どちらを優先したいですか。

依頼者：

今のお客さまの再購入を増やしたいです。

「売上を伸ばす」という大きな目的が、既存顧客の再購入へ絞られました。

次の質問：守る条件を確認する

AI：

施策を考えるうえで、行わないと決めていることはありますか。

依頼者：

値引きはしません。

値引きの可否は、AIが一般論から決めることではありません。依頼者の条件として共有します。

次の質問：使える人手を確認する

AI：

施策を担当できる人は、何人ですか。

依頼者：

担当者一人で実施したいです。

この回答は希望する体制であって、どの案でも一人で実施できるという確認結果ではありません。

次の質問：判断に必要な不足を見つける

AI：

担当者が施策のために使える時間は、どの程度ですか。

依頼者：

まだ確認できていません。
実施できるかは断定せず、必要な作業を示してほしいです。

不明な情報を、AIの推測で確定しないことがポイントです。

次の質問：利用できる情報の範囲を確認する

AI：

今回の案づくりに使ってよい情報の範囲を教えてください。

依頼者：

ここで共有した架空の条件だけを使います。
実在する顧客の情報や未許可の記録は使いません。

必要な情報だからといって、渡してよいとは限りません。

最後に、今回できる作業の範囲を決める

AI：

具体的な商品や予算は未確認です。
今回は、仮案と実施前の確認事項を作るところまででよいですか。

依頼者：

はい。まず仮案と確認事項を作るための依頼文を生成してください。
実施するかどうかは、その後に人が判断します。

「まだ不明なことがあるのに、すべてそろったことにする」のではありません。未確認事項を残したまま、今回の成果物を「実施が確定した計画」から「仮案と確認事項」へ限定しています。

5.4　生成された依頼文を、人が確認する

上の対話を基にすると、次のような依頼文が考えられます。これも教材用に作成した例です。

架空のお店について、既存顧客の再購入を増やす施策の仮案を作成してください。

確認済みの条件：
・値引きはしない。
・担当者一人での実施を想定して検討する。
・ここで共有した架空の条件のみを使う。
・実在する顧客情報や、利用が許可されていない記録は使わない。

未確認の事項：
・具体的な商品、予算、担当者が使える時間、利用可能な案内手段。
・再購入の数え方と、効果を確かめるための記録。

出力してほしいもの：
・条件に沿った施策の仮案。
・各案に必要な作業。
・実施前に確認すべき事項と、その確認先の候補。

未確認事項を事実として補わないでください。
一人で実施できることや、売上が伸びることを断定しないでください。
提案の作成にとどめ、顧客への送信や施策の実施は行わないでください。

人は、生成された依頼文が自分の意図を反映しているか、条件を強めたり弱めたりしていないかを確認します。例えば「担当者一人で実施したい」が「一人で確実に実施できる」に変わっていれば、希望が確認済みの事実にすり替わっています。

AIがもっともらしい条件を追加した場合も、勝手に採用しません。予算や期限が書かれていたら、依頼者が実際に伝えたものかを見直してください。

依頼文の「送信しない」という指示は、許可範囲を伝えるものです。実際の送信権限を無効にする設定とは異なります。ツールを接続する場合は、権限や承認の仕組みも別に確認します。

5.5　質問が止まらないとき、答えられないとき

一問ずつ聞いてもらっても、対話が適切に終わるとは限りません。細部の質問が続く場合は、今回の成果物を作るために何が不可欠かを整理してもらいます。

ここまでの回答を整理してください。
今回の成果物に不可欠な未確認事項と、
仮案を作る段階では未確認のまま残せる事項を分けてください。
不足を推測で埋めず、作成可能な範囲を説明してください。

これも整理の依頼であり、AIの分類が正しいと保証するものではありません。判断に不可欠な不足が残るなら、確認事項の一覧を作って止めます。

回答できない質問には、「分からない」「今は確認できない」「利用条件上伝えられない」と答えて構いません。利用不可の情報を求められたら、入力せず、別の情報で進められるかを検討します。

メタプロンプト生成法は、考えることをすべてAIへ任せる方法ではありません。AIの質問を手掛かりに、依頼者自身が目的や前提を明確にする方法です。

第6章　背景確認を、仕事の順番に組み込む

6.1　背景確認から条件照合までを、一続きにする

質問によって背景が整理できても、そのまま提案を採用してよいわけではありません。背景の確認は、仕事全体の一部です。

お店の例では、次の四工程で整理できます。

工程	AIが支援すること	人が確認すること	次へ進む条件
背景を確認する	必要な情報を質問し、回答を整理する	回答の正確さ、利用できる範囲	事実・不明・利用不可が区別されている
依頼文を生成する	対話を踏まえて依頼文を作る	意図、条件、未確認事項	勝手な条件や自動実行の指示がない
提案を作成する	確認済みの依頼文に沿って仮案を作る	出力の範囲、根拠、未確認の扱い	条件との照合に必要な内容がある
条件と照合する	案と条件の対応整理を支援する	条件への適合、実施可能性、根拠	採用・修正・保留の理由を説明できる

メタプロンプト生成法が扱うのは、最初の背景確認と依頼文の生成です。人が依頼文を確認してから、改めて提案作成を依頼します。依頼文が生成されたことを、提案作成や現実の実施への自動的な承認にしません。

6.2　工程を分ける理由は、途中の判断を見えるようにするため

一つの指示で多くの処理を頼めば、操作回数は減るかもしれません。しかし、どの前提で、どの処理を行い、どの段階で誤ったのかが見えにくくなる場合があります。

例えば、背景確認を飛ばして値引き案ができた場合、文章だけを書き直しても、なぜ値引き案が出たのかは分かりません。値引きしない条件をまだ伝えていなかったのか、伝えた条件が案に反映されなかったのかで、対応は違います。

工程を分けると、入力、出力、次へ進む条件をそれぞれ確認できます。すべてを細かく分ける必要はありませんが、重要な判断を含む境目は見えるようにします。

6.3　どの成果物を次の工程へ渡すかを決める

同じ対話の中でも、古い条件や不採用の案が残ることがあります。次の工程には、現在の条件を整理したものを渡します。

例えば、店の狙いが「新規客の獲得」から「既存客の再購入」に変わったなら、古い狙いと混ぜず、現在有効な条件を明記します。採用しなかった案を渡すときは、どの条件に合わなかったかも添えます。

引き継ぐ内容は、次のように整理できます。

現在の目的：既存顧客の再購入を増やすための施策の仮案を作る。
有効な条件：値引きなし、担当者一人を想定。
未確認：作業に使える時間、商品、予算、案内手段。
この工程の範囲：案と確認事項を作る。施策は実施しない。

会話の全文を渡すことが、必ずしも最も分かりやすい引き継ぎになるわけではありません。重要な条件を要約する場合も、元の意図や留保を落とさないように確認します。

6.4　順番は、依存関係から考える

依存関係とは、ある作業を進めるために、別の作業の結果が先に必要になる関係です。例えば、利用できる案内手段が不明なら、その手段を前提にした実施計画は確定できません。

一方、案の候補を見ながら必要な背景に気付くこともあります。初期案を作ること自体が悪いのではありません。初期案であることを明示し、未確認のまま実施判断へ進めないことが重要です。

順番を固定的に暗記するより、「この判断には何が先に分かっている必要があるか」と考えてください。必要なら前の工程へ戻ることも、仕事の設計に含まれます。

第7章　止める・戻す・人へ引き継ぐ条件を決める

7.1　情報不足と、条件に合わない案を区別する

「うまくいかなかったので、もう一度頼む」だけでは、問題が繰り返されるかもしれません。何が問題かを分けて、戻り先を決めます。

見つかった問題	問題の種類	戻る先・対応
値引きしてよいか分からない	背景情報が不足	依頼者に条件を確認する
値引きなしと伝えたのに、値引き案が出た	既知の条件への不適合	提案を修正する
「効果がある」と書かれているが根拠がない	根拠が不足	根拠を調べ、確認できなければ主張を弱めるか保留する
顧客への送信が提案され、利用許可が不明	実施の許可が未確認	送信せず、人へ確認する
計算ツールが失敗した	実行が未完了	原因を確認し、結果を得たことにしない

情報がないのか、ある情報を使えていないのか、実行が失敗したのかを区別すると、直す対象が明確になります。

7.2　止めることは、仕事を放棄することではない

必要な確認ができないときに止めるのは、根拠のない成果物を採用しないためです。ただし、「できません」で終わらず、何が不足し、次に誰が何を確認すればよいかを残します。

現在できていること：
・値引きをしない条件に沿った施策の仮案を整理した。

採用を保留する理由：
・担当者が使える時間と、利用できる案内手段が未確認である。

次の確認：
・店舗の担当者に作業手順と使える時間を確認する。
・案内手段の利用ルールと権限を確認する。

判断の保留は、作業の全停止と同じではありません。案の比較や確認事項の整理は進められても、実施の承認は出さない、という分け方ができます。

7.3　生成・採用・実施を別の段階として扱う

案内文の生成、案内文の採用、顧客への送信は、異なる行為です。

文章案を生成する
        ↓ 内容を確認する
使う文章を人が選ぶ
        ↓ 利用ルール・対象・権限を確認する
必要な承認を得て、許可された範囲で送信する

AIに下書きを頼むことは、送信まで許可することではありません。研究でも、実験計画の提案と実験の実施は別です。資料作成でも、原稿の生成と公開は別です。

実際に使うときは、誤操作や不適切な実行を防ぐ仕組みを検討します。接続するツールの権限を必要な範囲に制限することや、重要な操作に承認を設けることが、その例です。ただし、具体的な設定方法や保証される範囲は製品ごとに異なります。

本書は、特定システムの権限設定を済ませたことを示すものではありません。「禁止」と書いた文章や工程図だけで、安全が保証されると考えないようにしてください。

7.4　繰り返しには、終了する条件を置く

AIに「もっとよい案を」と頼み続けても、どこまで改善したかが分からなければ終わりません。先に合格条件と、試行を止める条件を決めます。

停止条件には、必要な条件を満たした、追加の検討に必要な情報がない、許可された時間や費用の上限に達した、といったものがあります。危険な操作や利用不可の情報が必要になった場合も、進めずに確認します。

回数や予算の上限は、作業に合わせて人が決めます。本書に、すべての仕事に共通する最適な回数はありません。また、上限に達したことを、成果物が正しいという証明にはできません。

第8章　専門知識は、何を確かめるかを決める土台になる

8.1　専門性は、最後の採点だけに使うものではない

専門知識や業務理解は、AIの答えを最後に読んで評価するときだけに使うものではありません。何を入力するか、どの順番で処理するか、どの結果を使うかを決める場面でも必要になります。

お店の例なら、「再購入」という言葉の意味を決めることも専門的な判断の一部です。同じ商品を再び買うことなのか、別の商品でもよいのか、どの期間内の購入を数えるのかで、必要な記録が変わります。

場面	必要な問い	確認先の例
入力を選ぶ	再購入をどう数えるか	店舗の記録の定義、集計ルール
手順を組む	一人で実施できる作業量か	実際の作業手順、担当者
結果を読む	同じ条件で変化を比べられるか	定義と対象期間をそろえた記録

分野の知識があると、重要な違いに気付きやすくなります。ただし、専門家なら誤らないという意味ではありません。根拠と適用範囲を確かめる必要は、専門家にもあります。

8.2　確認できる基準へ、言葉を具体化する

「一人で実施できる」「効果がある」「分かりやすい」といった言葉だけでは、判断が人によって変わります。何を見て判断するかまで具体化します。

例えば、「一人で実施できる」なら、準備、実施、問い合わせ対応、記録といった作業を洗い出し、どの時間帯に誰が行うかを確かめます。担当者一人という人数だけでなく、その人に別の業務があることも考慮します。

ここでAIに支援してもらえるのは、作業項目の候補を出すことや、確認事項を整理することです。実際の担当者がどの程度の時間を使えるかは、現場への確認が必要です。

8.3　条件への適合、結果の変化、因果効果を分ける

施策案の評価では、少なくとも次の三段階を区別します。

段階	確かめること	それだけでは言えないこと
条件への適合	値引きなしなどの条件に合うか	実施すれば売上が伸びる
結果の変化	実施前後などで再購入の数が変わったか	その施策が変化の原因である
因果効果の検討	他の要因と区別して施策の影響を考えられるか	どの店でも同じ効果がある

例えば、施策後に再購入が増えても、季節、来店者数、商品構成なども変わっているかもしれません。前後の数字が変化しただけでは、原因を一つに決められません。

因果効果を検討するには、実施条件や比較対象を設計し、必要に応じて統計や実験計画の知識を使います。どの方法でも、顧客や研究参加者に関わるルール、実施の許可、データの利用条件を先に確認します。本書は、実地の効果測定や実験の実施を要求するものではありません。

8.4　数値の計算と、その意味を別々に確かめる

第2章の財務分析を思い出してください。割り算が正しくても、分母が病院全体の収益か、法人全体の収益かで意味は変わります。

数値を使うときは、計算の前後で次を確認します。

確認すること	例
指標の定義	売上、収益、損益、費用のどれか
年度・期間	同じ年度か、年度の始まりと終わりは同じか
単位	円、千円、百万円が混ざっていないか
対象範囲	一店舗、一施設、法人全体のどれか
公開原資料との対応	どの表・列・注記から取った値か
欠損の扱い	未取得や未確認をゼロにしていないか
説明できる範囲	観測した対象の結果か、全体を推計したものか

ツールが計算を実行したことは、この確認の代わりにはなりません。逆に、文章による説明だけでは見えなかった計算の取り違えを、コードと出力へ戻ることで見つけられる場合があります。

8.5　分からないときは、確認先を選べることが大切

まだ専門知識が少ないからといって、AIとの対話を始めてはいけないわけではありません。「どこが分からないか」を整理し、適切な資料や人へつなげればよいのです。

分からないこと	最初の確認先の例
用語や指標の意味	教科書、原資料の定義・注記
製品の現在の機能	公式ドキュメント、利用環境の管理者
現場で実施できるか	担当者、業務手順、運用ルール
計算が正しいか	元値、算式、コード、計算結果
専門的な採否判断	指導教員や、その分野の詳しい人

AIに確認先の候補を聞くことはできます。ただし、AIが挙げた資料やURLの存在、内容、適用範囲は自分で確認します。確認できないときは、その理由とともに保留します。

第9章　AIとの対話を、自分の学びに変える

9.1　完成した仮説ではなく、疑問から始めてもよい

「自分で考えてからAIを使う」と聞くと、利用前に完成した答えが必要だと思うかもしれません。本書で求めるのは、正解の用意ではありません。

例えば、「一人で実施できるか分からない」「論文の測定条件が違うと、何が比べられなくなるのか知りたい」という疑問から始められます。メタプロンプト生成法で、不足をAIに質問してもらうこともできます。

大切なのは、分かることと分からないことを区別し、答えを受け取った後に、根拠を確認することです。

9.2　対話の後に、原資料や現場へ戻る

AIが「作業時間を確認しましょう」と提案したら、実際に必要な作業を整理し、手順書や担当者に確認します。AIが「この論文を参照してください」と答えたら、その論文と該当箇所を確かめます。

別のAIにも同じ質問をして答えが一致したとしても、それだけで独立した根拠が増えたとは限りません。似た誤りや、共通の不確かな情報に基づいている可能性があります。

AIの回答は、調べる方向を見つける手掛かりとして使えます。確認の完了は、手掛かりを得た段階ではなく、必要な原資料や実際の条件と照合した段階で判断します。

9.3　振り返りは、次に直す一つを決めるために残す

毎回長いレポートを書く必要はありません。次の三点を一行ずつ記録するだけでも、次の試行の手掛かりになります。

足りなかった情報：
確かめた根拠：
次に変えることと、その理由：

お店の例なら、次のように書けます。これは実施記録ではなく、記入の見本です。

足りなかった情報：担当者が案内文の準備に使える時間。
確かめた根拠：今回は未確認。実際の手順と担当者への確認が必要。
次に変えることと、その理由：
実施できると断定しないため、案に必要な作業を先に示してもらう。

確認していないのに「確認した」と書く必要はありません。未確認のまま残した理由と、次の確認方法を書くことも学びの記録です。

9.4　うまくいったかを、速さだけで判断しない

AIを使って短時間で文章ができても、原資料の確認や修正に大きな手間がかかれば、仕事全体がよくなったとは限りません。

「今回は何を改善したかったか」に合わせて、振り返る対象を決めます。確認漏れが減ったか、条件に合わない案を見分けられたか、採用理由を説明できるかなども対象になります。

ただし、自分が便利だと感じたことと、学習効果が実証されたことは別です。本書の演習や自己点検を終えたことだけで、専門能力の向上や実務での成果が証明されたとは扱いません。

第10章　Microsoftの公開例を、仕事の設計として読む

10.1　Copilot Cowork――アプリをまたぐ仕事を支援する

講義の準備資料では、Microsoft Learnの公式概要を基に、Copilot Coworkを、依頼を手順に分け、Microsoft 365のアプリをまたいで作業を進めるAIとして紹介しています。資料の検索や文書作成などが例です。

この説明からは、質問への回答だけでなく、仕事を構成する処理をつなぐ方向を読み取れます。メール送信などの重要な操作では利用者の承認を求める、という確認点もあります。

学習上の問いは、「何でも自動化できるか」ではありません。どの情報を参照し、どのアプリで何を行い、どの操作で人の確認を挟むかです。実際に利用できる機能や承認の対象は、公式の最新情報と、自分の環境で確認する必要があります。

10.2　Copilot for legal――専門業務の基準を作業へつなぐ

法務向けのCopilot for legalについては、指定された「ビジネス＋IT」の記事の公開範囲を基に説明します。記事では、Word上で自社の審査基準に沿った契約書のレビューや修正案の提示を支援し、Coworkでは契約上の義務や期限の抽出などを扱うと紹介されています。

契約レビューに使うプレイブックとは、何を認め、何に注意し、どのように修正を検討するかをまとめた審査方針や基準です。一般的な契約の知識だけでなく、自社の基準を作業へ結び付ける点に注目します。

Copilot CoworkとCopilot for legalは、単に競合する二つの製品を比較する関係としては扱いません。アプリをまたぐ仕事の仕組みと、法務に固有の手順・基準を組み合わせる例として読みます。

本講義の運用上の原則として、内容の検証と法的判断は人が担います。本書は、AIによる契約レビューを専門家の判断の代わりに使うことを推奨するものではありません。

10.3　機能紹介と、効果の実証を混同しない

公開ページに機能が記載されていること、特定の環境で実際に利用できること、業務の成果が上がったことは、それぞれ異なる主張です。

本書の製品説明は、講義準備資料に記録された2026年10月24日時点の確認内容に基づきます。Copilot for legalの指定記事は2026年10月16日公開の二次情報です。会員限定部分や、取得できなかったMicrosoftサポート本文を確認済みとは扱っていません。本書作成時の追加のWeb調査も行っていません。

そのため、ライセンス、地域、提供段階、利用可能な機能などを固定的に断定しません。製品を使う場合は、公式情報と所属組織の利用条件を確認してください。本書の事例紹介は、Microsoft全社の生産性効果や、利用者全員に同じ成果が出ることの証明ではありません。

第11章　考え方を別の場面へ移す演習

11.1　演習の取り組み方

以下は、すべて授業後の練習です。実データや実サービスを使う必要はありません。AIが利用できない場合は、紙やメモだけで取り組めます。

各問題では、結論だけでなく「なぜそうするか」を短く書いてください。第14章に解答・解説をまとめていますが、語句を一致させるための暗記問題ではありません。

11.2　演習1：目的・成果物・合格条件を分ける

大学院の研究会に向けて、「AIで発表を分かりやすくしたい」と考えています。発表の聴衆は、同じ専門分野の人だけではありません。

今回の作業を「発表資料の構成案を作ること」に限定した場合、目的、成果物、合格条件を分けて書いてください。未公開の研究内容をAIへ入力してよいかは、まだ確認できていません。

11.3　演習2：情報を整理し、不明と利用不可を分ける

架空のお店で、既存顧客の再購入を増やすための施策の仮案を作ります。次の情報について、どう扱うかを考えてください。

情報	現在の状態
値引きしない方針	確認済み。AIへ伝えてよい
担当者が使える時間	未確認
実在顧客の購入履歴	手元にはあるが、AIへの入力は許可されていない
今回と関係のない他部署の会議記録	手元にある

「手元にあるから渡す」「不明だから推測する」としないための扱いを書いてください。

11.4　演習3：生成された依頼文の問題を見つける

依頼者が確認したのは、既存顧客の再購入を増やしたい、値引きをしない、担当者一人を想定している、という条件です。作業に使える時間と案内手段は未確認です。

AIが、次の依頼文を生成しました。

既存顧客の再購入を増やすため、
担当者一人で確実に実施できるメール施策を作成してください。
完成後は、すぐに全顧客へ送信してください。

確認済みの条件、未確認事項、許可範囲に照らし、どこを修正すべきか考えてください。

11.5　演習4：問題ごとに戻り先を変える

次の三つの状況で、戻る工程と、その理由を書いてください。

状況	考えること
値引きの可否をまだ聞いていなかった	何を誰に確認するか
値引きなしと伝えたのに、値引き案が出た	何を修正するか
利用ルールが不明なのに、顧客への送信を求められた	何を止め、誰が判断するか

11.6　演習5：条件への適合と、売上への効果を区別する

架空の施策案について、「値引きをせず、既存顧客向けである」という条件は確認できました。実施後の再購入の件数も増えたとします。ただし、季節や来店者数などの変化は調べていません。

次の主張のうち、何が確認でき、何がまだ言えないかを説明してください。

この案は、確認した二つの条件に合っている。
再購入の件数が増えた。
この施策だけが原因で、再購入が増えた。

11.7　練習問題A：店舗と会社の売上を比較する

公開資料の店舗Aの売上と会社B全体の売上を、AIに比較させたい。年度・単位は未確認

「足りない情報」「進めてよい条件」「確かめ方」を、一言ずつ書いてください。店舗Aと会社Bは架空です。

11.8　練習問題B：施設と法人の費用を比較する

公開資料の施設Cの費用と運営法人D全体の費用を、AIに比較させたい。年度・単位は未確認

問題Aと同じ三点を書いてください。施設Cと運営法人Dは架空です。問題Aの解答を写すのではなく、この問題でどの資料の、どの範囲を確認すべきか考えてください。

第12章　授業後の課題――自分の一作業の設計図を作る

12.1　大きな仕事から、小さな一作業を選ぶ

自分の研究、学習、仕事から、目的と確かめ方を決められる一作業を選びます。「修士論文を完成させる」全体よりも、「利用できる論文の比較項目を整理する」など、範囲を限定した方が設計しやすくなります。

取り組みやすい例は、公開資料の比較表、発表の構成案、架空条件による施策の仮案などです。実在の個人情報や未公開資料を使わなければ成立しない作業は、練習の題材にしないでください。

12.2　五つの問いに沿って書く

項目	書くこと
目的・成果物	何のために、今回何を作るか
コンテキスト	必要・不足・利用不可の情報は何か
工程と順番	何を先に確認し、どこで止め、どこへ戻るか。誰が採用・実施を決めるか
専門的な検証	何を根拠に、どこまでできれば採用するか
次の学び・試行	何を調べ、次のどの作業で試すか

不足が分からなければ、その旨を書いて構いません。ただし、「AIに聞く」だけで終わらず、何の目的のために、何を整理する質問をしてもらうのかを書きます。必要性や利用可否が分からない情報も、分かったことにせず、次の確認方法を残します。

そのままメモへ写して使える記入欄です。

目的・成果物：

コンテキスト：
・必要で、既にあり、利用できる情報：
・必要だが、未確認・不足している情報：
・利用条件上、渡せない情報：
・不足自体が分からない場合の、次の確認方法：

工程と順番：
・先に確認すること：
・依頼文の生成と、人による確認：
・案を作る工程：
・次へ進む条件：
・止める条件と戻り先：
・採用や実施を決める人：

専門的な検証：
・採否を判断する基準：
・照合する原資料・計算・手順・詳しい人：
・まだ確かめられないこと：

次の学び・試行：
・次に調べること：
・試す場面と時期の目安：
・採用・修正・保留の理由：

12.3　お店の例で、記入の具体性を確かめる

項目	記入見本
目的・成果物	既存顧客の再購入を増やすための施策の仮案と、実施前の確認事項を作る
コンテキスト	値引きなし、担当者一人を想定。使える時間、商品、予算、案内手段は未確認。実在する個人情報や未許可の記録は渡さない
工程と順番	背景の質問、依頼文の生成、人の確認、仮案の作成、条件照合の順。不明なら背景確認へ、条件外なら案の修正へ戻す。採用・実施は人が判断する
専門的な検証	店の条件と照合する。実施可能性は作業手順と担当者に確認する。売上効果は別に検討し、未確認のまま断定しない
次の学び・試行	許可された環境で架空条件を使い、依頼文を作るところから試す。使えない場合は設計のみとし、不足と判断理由を記録する

これは架空の設計見本であり、施策の実施や効果の記録ではありません。自分の設計では、確認先や判断する人を、利用可能な範囲で具体化してください。

12.4　三つの基準で自分の設計を見直す

基準	自己点検すること
情報	必要・不足・利用不可と、それぞれの扱いが具体的か。不足が不明なら、理由と次の確認方法があるか
条件	先に確認する前提、進める条件、止める条件、戻り先が具体的か
検証	採否の根拠と、照合する原典・計算・詳しい人などが具体的か

該当する情報がないと判断した場合も、その理由を説明します。単に欄が埋まっていることより、書いた判断を自分の言葉で説明できることを重視します。

12.5　取り組む時期と、提出について

授業後1週間以内を目安に、次の一作業で試してみてください。これは正式な提出期限ではありません。提出先、提出方法、必須・任意の別、成績評価の有無は、本書では設定していません。授業担当者から案内があれば、その指示を確認してください。

提出の指定がなければ、自己点検用のメモとして取り組めます。AI利用が許可されていない場合は、無理に実行せず、設計と確認先の整理までで構いません。

AIを使った場合も、使わなかった場合も、最後に「何を採用・修正・保留し、なぜそうしたか」を一行残してください。

第13章　迷いやすい点を整理する

13.1　最初から詳しい指示文を書けないと使えないのか

使い始めるために、完成した依頼文は必要ありません。目的や疑問から対話を始め、AIに不足を質問してもらえます。ただし、対話で分からなかったことまで、分かったことにしないようにします。

13.2　メタプロンプトを使えば、人の専門知識は要らないのか

要らなくなるわけではありません。質問の漏れ、誤った前提、不適切な確認先に気付くために、知識や業務理解が役立ちます。まだ知らない部分は、原資料や詳しい人に確認します。

AIが質問してくれた項目だけを、確認事項のすべてだと考えないことが重要です。

13.3　AIに根拠を書かせれば、検証は終わりか

終わりではありません。出典が存在するか、該当箇所がその主張を支えているか、今回の対象に適用できるかを確認します。理由が詳しく書かれていても、その理由自体が不正確な可能性があります。

本書でいう検証は、AIの内面の思考過程を推測することではなく、入力資料、算式、コード、出力、現場の条件といった確かめられるものを照合することです。

13.4　情報を少なくすれば、安全で正確になるのか

単に少なくすればよいわけでもありません。必要な条件を省けば、今回の仕事に合わない提案になり得ます。情報の量ではなく、必要性、正確さ、時点、利用条件を確認します。

13.5　公開情報なら、そのまま全部渡してよいのか

公開されていることと、利用条件がないことは同じではありません。資料の利用条件や著作権、サービス側の規約、所属組織のルールを確認します。目的に必要な範囲で使い、出典を残してください。

13.6　毎回、人が全部確認しないといけないのか

確認の深さは、誤りが与える影響や、作業の性質によって変わります。架空例のアイデア出しと、契約・研究・顧客対応に関わる判断を同じ扱いにはできません。

ただし、「AIが自信を持って答えた」「以前うまくいった」という理由だけで、必要な確認を省かないようにします。何を自動化し、どこで人が判断するかは、利用ルールと仕事のリスクに合わせて設計します。

13.7　AIを使ってもよいか分からないときは、どうするか

入力せずに、利用条件を確認します。授業の課題では、架空の題材へ切り替えるか、設計と確認先の整理までにしてください。匿名化や要約を自分で行ったからといって、許可が不要になるとは判断しません。

第14章　演習の解答・解説

14.1　演習1：成果物を、発表の成功そのものと混同しない

解答例は次のとおりです。

項目	解答例
目的	専門分野の異なる聴衆にも、発表の要点を伝えやすくする
成果物	発表資料の構成案と、用語説明・具体例を入れる位置
合格条件	聴衆の前提知識に合わせた順序になっている。未説明の専門用語を確認できる。根拠のない結果や主張を追加していない
利用上の扱い	未公開内容の入力許可を確認するまでは使わず、公開情報または架空の題材で構成だけを検討する

構成案ができたことと、聴衆の理解を測定できたことは別です。また、許可が未確認の研究資料を、AIに判断させるために先に入力してはいけません。

14.2　演習2：「ある」と「使える」は違う

情報	解答例
値引きしない方針	必要で確認済み、利用可能な条件として伝える
担当者が使える時間	未確認とし、担当者や業務手順への確認を計画する
実在顧客の購入履歴	入力しない。許可された集計情報などで代替できるかを検討する
関係のない他部署の会議記録	目的との関係がないため、今回の入力から外す

ポイントは、情報の存在、必要性、利用可否を別々に考えることです。代替情報を作る場合も、元の記録を勝手に加工・共有してよいという意味ではありません。

14.3　演習3：希望を事実に変えず、未許可の実行を追加しない

問題の依頼文には、次の不備があります。

記述	問題	修正の方向
一人で確実に実施できる	作業量を確認せず、希望を確定事項に変えている	必要な作業を示し、実施可能性は未確認とする
メール施策	利用できる案内手段が未確認	手段を確定せず、利用条件を確認する
完成後、すぐに全顧客へ送信	提案作成から、未許可の実行へ範囲が広がっている	送信を指示せず、人の判断と許可を別工程にする
値引きなしの条件がない	確認済みの重要な条件が落ちている	現在の有効な条件として明記する

修正例です。

既存顧客の再購入を増やすための施策の仮案を作ってください。
値引きはしません。担当者一人での実施を想定して検討しますが、
使える時間と案内手段は未確認です。
各案に必要な作業と、実施前の確認事項を示してください。
顧客への送信や施策の実施は行わないでください。

この禁止文だけで実際の送信権限が制限されるわけではない点も、併せて確認します。

14.4　演習4：不足なら確認へ、不適合なら修正へ戻る

状況	解答例
値引きの可否を聞いていない	背景確認へ戻り、依頼者に条件を確認する
値引きなしなのに値引き案が出た	条件を保持したまま、提案の修正へ戻る
送信の利用ルールが不明	送信を止め、必要な許可や権限を担当者・管理者などに確認する

すべてを「AIにもう一度考えさせる」で済ませないことがポイントです。条件は人に確認する必要があり、実行の許可をAIの推測で補ってはいけません。

14.5　演習5：観察した変化だけで、原因を断定しない

「確認した二つの条件に合っている」は、問題文の範囲で言えます。ただし、一人で実施できるかなど、ほかの条件まで確認できたことにはなりません。

「再購入の件数が増えた」は、問題文で与えた観測結果として扱えます。実際の仕事では、数え方、対象、比較期間がそろっているかも確かめます。

「この施策だけが原因で増えた」は、まだ言えません。季節や来店者数などの変化を調べておらず、それらと区別した検討をしていないためです。

「効果がない」と断定することもできません。ここでの正しい留保は、効果の有無を確定するための根拠がまだ足りない、ということです。

14.6　練習問題A：対象範囲を、数字の大きさより先に確認する

解答例です。

観点	解答例
足りない情報	年度・単位・売上の定義と、一店舗か会社全体かという対象範囲
進めてよい条件	同じ年度・単位・対象範囲にそろえられるかを先に確認し、そろえられなければ、その条件を前提とする比較を保留する
確かめ方	公開原資料の売上表、対象列、単位、集計範囲の注記を確認し、使う値と照合する

年度と単位が同じでも、一店舗と会社全体では範囲が異なります。そのまま数字の大小から、店舗の運営や業績の優劣を結論付けてはいけません。

なお、対象範囲が異なる数値を並べることが、あらゆる目的で禁止されるわけではありません。例えば、資料に記載された規模を別々に示すなら、異なる範囲であることを明記できます。ただし、それは同条件で優劣を比べる作業とは別です。比較の目的や方法を変更するなら、何を判断できるかを改めて定めます。

14.7　練習問題B：費用の定義と、法人に含まれる範囲を確認する

解答例です。

観点	解答例
足りない情報	年度・単位・費用の定義、施設Cと法人Dの対象範囲
進めてよい条件	同じ年度・単位・対象範囲にそろえられるかを先に確認し、そろえられなければ、その条件を前提とする比較を保留する
確かめ方	公開原資料の費用表、施設別の列、単位、会計上の集計範囲・費用区分の注記と照合する

法人全体には複数の施設や別の事業が含まれるかもしれません。「費用」という名称が同じでも、どの費用を含むかが違う可能性があります。

費用が少ないことだけから、効率やサービスの質を判断することもできません。何を目的に比較するのかを先に決め、その判断に必要な条件を確認します。

14.8　練習問題A・Bに共通する自己点検基準

次の簡易基準で、自分の記述が具体的になっているかを確認できます。

観点	1：記述できている	0：未記述・曖昧・矛盾する
不足の特定	年度・単位・対象範囲について、未確認・不一致の項目を一つ以上具体的に挙げる	「情報が足りない」だけ、または不足を特定せず比較する
進める条件	同じ年度・単位・対象範囲に揃えられるかを先に確認し、揃えられなければ比較を保留すると書く	「気を付ける」だけ、または条件未確認のまま比較・断定する
検証先・方法	公開原資料の該当箇所を特定し、対象列・単位・定義のどれかと照合すると書く	「AIに聞く」「確認する」だけで検証先・照合対象が不明

同じ語句でなくても、意味が満たされていれば1とします。各観点0〜1、合計0〜3は、記述の具体性を確かめる本講義用の簡易基準です。妥当性が検証された能力尺度でも、成績評価でもありません。

問題A・Bは、どちらも授業後の練習です。一方を講義前、もう一方を講義後の測定として、能力の変化や講義の効果を計算しないでください。

第15章　用語を自分の言葉で説明する

用語	本書での説明
生成AI	入力に応じて文章などを生成するAI
AIエージェント	AIモデルと工程・ツールなどを組み合わせ、目的に向けて仕事を進める仕組み
プロンプト	AIへの指示や入力。依頼の文章など
コンテキスト	今回の仕事を理解するための背景。本書では特に、AIにまだ伝えていない事情を扱う
コンテキストエンジニアリング	AIが仕事に使う情報や、その与え方を設計する考え方
メタプロンプト生成法	本講義で紹介する、不足を一問ずつ質問してもらい、回答を基に依頼文を生成してもらう方法
プロセス	作業の順番、受け渡し、途中の確認や戻り方
Skill	仕事の進め方や確認基準などを再利用できる形でまとめたもの
外部ツール	検索、計算、文書処理などを実行する仕組み
ハーネスエンジニアリング	AIが使う環境、ツール、権限、手順、確認方法などを整える設計
知識グラフ	情報どうしの関係を整理したもの。出典との対応も重要になる
Jupyter Notebook	コード、説明文、実行結果などを記録できる文書形式・実行環境
活用と探索	有望な領域を深めることと、まだよく分からない領域を調べること
反証	仮説に反する根拠や、成立しない条件を調べること
停止条件	試行や実行を続けずに止めるための条件
合格条件	成果物を採用したり、次の工程へ渡したりしてよいかを決める基準
因果効果	ほかの要因と区別して考える、ある施策が結果へ与えた影響

用語を暗記したかよりも、自分の作業でどれが何に当たるかを説明してみてください。「コンテキストなら、今回は聴衆の前提知識と利用できる資料です」と具体化できることが大切です。

第16章　事例の出典と、確認できていない範囲

16.1　本書の位置付けと、説明の種類

本書の主な入力は、講義の制作指示書「第04回_プレゼンテーションコンテキスト.md」です。スライドの操作指示や制作担当者向けの情報を除き、独習に必要な説明、架空の対話例、演習と解説を加えています。第1〜3回の講義を受けていることは、読解の前提にしていません。

内容には、次の種類が含まれます。

種類	本書での扱い
講師が説明した開発・制作事例	講師の説明に基づく事例として紹介する
保存済み分析結果についての確認記録	講義準備資料が記録する確認範囲に限って紹介する
公開製品の機能説明	確認日と一次・二次情報の別を示す
架空のお店、対話、設計見本	考え方を説明する教材例とし、実績とは扱わない
学び方や設計の提案	実践のための整理であり、効果が実証済みとはしない

講師の開発事例と、Microsoftの公式製品や全社的な実績を混同しないでください。また、参考URLを掲載することは、リンク先の全内容を確認したことや、現在の動作を保証することを意味しません。

16.2　参考資料

資料	参照目的と留保
kotonoha	講師が使用を説明した文書作成支援の開発事例。全機能の再調査はしていない
AIRA	講師開発の研究支援AIへの参照先。本書では実装・探索制御の作動や研究成果を検証していない
Jupytermind	講師開発の分析支援事例への参照先。保存出力の存在と、全自律操作の履歴は別
浜松医科大学2025年度財務諸表・PDF30ページ	業務損益率の公開原資料への参照先。講義準備資料は保存済み資料との対応を記録しているが、本書では再取得・訂正版確認をしていない
Copilot Cowork概要（Microsoft Learn）	講義準備資料に2026年10月24日の確認記録がある公式概要。利用時の提供条件は別途確認する
Copilot for legalの紹介記事（ビジネス＋IT）	2026年10月16日公開記事の公開範囲を基にした二次情報。会員限定部分は未確認

製品の機能説明にはMicrosoftの公式文書も用いていますが、本書そのものをMicrosoftの製品仕様書や、契約・研究・経営に関する専門的助言として扱うことはできません。

16.3　この教材からは言えないこと

本書だけでは、AIRAが新材料を発見した、財務分析が経営改善を実現した、AIの利用で受講生の能力が向上した、といった結論は出せません。実験、実施、追跡、比較など、それぞれの主張に必要な検証を行っていないためです。

AIが作業を進める仕組みを理解することと、個別のシステムが正しく作動し、成果を上げたと証明することは分けて考えてください。

おわりに――AIと仕事を設計する人へ

AIに不足情報を質問してもらっても、依頼文を作ってもらっても構いません。初めからすべてを知り、自分だけで完璧に設計する必要はありません。

ただし、何を伝え、なぜその順番で進め、何を根拠に使うと決めたかは、自分の言葉で説明できるようにしてください。確認できないことを保留する判断も、その説明に含まれます。

AIが答えを出す時代だからこそ、何を問い、何を実現したいのかが大切になります。皆さんがこれから学ぶ知識や積み重ねる経験は、その判断を支える土台です。

まずは、授業後の小さな一作業から。AIに答えをもらうだけでなく、AIと仕事を設計する人へ、一歩踏み出してみてください。