使う場面

ChatGPTやGrok、Geminiが「何をするものか」を理解するとき。

確認ポイント

出力は入力や設定で変わるため、結果をそのまま正解とせず確認する姿勢が役立ちます。

使う場面

ChatGPT・Claude・Gemini・Grokの仕組みを理解するとき。

確認ポイント

何でも正しく答える存在ではなく、入力や参照情報で出力が変わるため、重要な内容は確認が必要です。

使う場面

「どのモデルを選ぶか」で迷ったとき。

確認ポイント

高性能なほど良いとは限らず、速度・コスト・用途のバランスで選ぶと判断しやすくなります。

使う場面

思った通りの回答が出ないとき、書き方を見直す場面。

確認ポイント

目的・前提・出力形式を具体的に伝えると、結果が安定しやすくなります。

使う場面

AIの振る舞いを一貫させたいとき。

確認ポイント

指示の優先順位や設定できる範囲はサービスごとに異なります。役割を指定しても、事実の正しさは別に確かめます。

使う場面

AIの回答をそのまま使ってよいか判断するとき。

確認ポイント

数値・固有名詞・最新情報は誤りが混じることがあるため、一次情報での確認が安全です。

使う場面

画像を読ませたり、図を説明させたりするとき。

確認ポイント

対応する入力形式はモデルやプランで異なる場合があるため、事前の確認が役立ちます。

使う場面

モデルを学習させる処理と、実際に使う処理を区別するとき。

確認ポイント

問題を段階的に考えるReasoningとは意味が異なります。推論が速いことと、回答が正しいことも別です。

使う場面

回答を堅実にしたい、または発想を広げたいとき。

確認ポイント

低くても誤答は起きます。設定の可否や範囲はモデルによって異なり、同じ値でも結果の一致は保証されません。

使う場面

会話が長くなって回答がぶれてきたと感じるとき。

確認ポイント

画面に見える会話すべてが、毎回そのまま渡されるとは限りません。必要な前提は短く整理して伝え直します。

使う場面

最新情報や社内資料をもとに、根拠のある回答を作りたいとき。

確認ポイント

誤りを減らす助けにはなりますが、参照先の品質と、引用が主張を本当に支えているかは別に確認します。

使う場面

新しい制度・製品・人物について、回答が古くないか考えるとき。

確認ポイント

検索や外部資料を使える機能とは分けて考え、最新性が重要な内容は日付と一次情報を確認します。

使う場面

複雑な比較、数学、計画づくりなどに使うモデルを選ぶとき。

確認ポイント

長く考えた回答でも誤りは起きます。表示される説明が、内部の処理をそのまま示しているとは限りません。

使う場面

新しい会話でも、伝えた前提を引き継ぎたいとき。

確認ポイント

保存する情報、参照範囲、削除方法はサービスで異なります。現在のコンテキストや、モデルの追加学習とは区別します。

参考：Anthropic：コンテキストの設計

使う場面

長い会話や複数資料で、重要な情報が埋もれてしまうとき。

確認ポイント

量を増やすだけでなく、必要性・新しさ・参照元を見直します。不要な情報を除き、重要な条件を残します。

参考：Anthropic：コンテキストの設計

使う場面

まず簡単な指示で、どの程度できるか試すとき。

確認ポイント

モデルが事前に何も学習していない、という意味ではありません。形式が安定しない場合は例を添えて比べます。

参考：Google：プロンプト設計

使う場面

分類ラベル、文体、回答の長さなどを揃えたいとき。

確認ポイント

例の偏りや誤りも出力に影響します。例を見せることと、モデル自体を追加学習することは別です。

参考：Google：プロンプト設計

使う場面

過去の来店数と曜日のデータから、翌日の混雑を予測する。

確認ポイント

人がすべての判断ルールを書く方法とは異なりますが、目的やデータの選び方は人が設計します。

参考：Google: What is Machine Learning?

使う場面

文字画像から線や形の特徴を段階的に学び、書かれた数字を判別する。

確認ポイント

層を増やすだけで性能がよくなるわけではなく、データや学習方法も結果を左右します。

参考：Google: Neural networks / Google: Nodes and hidden layers

使う場面

「迷惑メールかどうか」の正解付きメールで、メールを仕分けるモデルを学習する。

確認ポイント

教師とは人が横で教えることではなく、学習時に正解が与えられることです。正解ラベルの誤りも学習に影響します。

参考：Google: Supervised Learning

使う場面

商品レビューを、似た内容のグループに分けて話題の傾向を調べる。

確認ポイント

見つかったグループに意味があるかは別途確認が必要です。正解ラベルがないことと、人の設計が不要なことは同じではありません。

参考：Google: What is Machine Learning? / Google: What is clustering?

使う場面

文章の一部を隠し、前後の文から隠れた語を当てる練習をさせる。

確認ポイント

人が一件ずつ正解を付けなくても学習できますが、課題の作り方と元データの品質は重要です。

参考：Google: Machine Learning Glossary

使う場面

ゲームで勝利につながる手を、プレイ結果の報酬から学習させる。

確認ポイント

報酬が高い行動が、人の本当の目的に合うとは限りません。報酬の設計を確かめる必要があります。

参考：Google: What is Machine Learning?

使う場面

問い合わせ文を「配送」「返品」「使い方」に振り分ける。

確認ポイント

カテゴリを探すクラスタリングとは目的が異なります。複数カテゴリを同時に付ける分類もあります。

参考：Google: What is Machine Learning?

使う場面

移動距離と混雑状況から、配達にかかる分数を予測する。

確認ポイント

「回帰」は過去へ戻るという意味ではありません。予測が実測値からどれだけずれるかを測って評価します。

参考：Google: What is Machine Learning?

使う場面

多数の問い合わせを内容の近いまとまりに分け、よくある質問を探す。

確認ポイント

距離の測り方やグループ数によって結果が変わります。グループ名や解釈が自動的に正しいとは限りません。

参考：Google: What is clustering?

使う場面

画像の画素を入力して、写っている物の種類を予測する。

確認ポイント

脳から着想を得た名前ですが、人の脳そのものを再現した仕組みではありません。

参考：Google: Neural networks / Google: Nodes and hidden layers

使う場面

文章の離れた箇所の関係を扱う、翻訳モデルの仕組みを理解するときに使う。

確認ポイント

特定のサービス名ではありません。入力を読む型、出力を作る型、その両方を持つ型があります。

参考：Vaswani et al.: Attention Is All You Need / Hugging Face: Transformer Architectures

使う場面

翻訳で次の語を作る際に、元の文のどの部分を参照するかを重み付けする。

確認ポイント

人間の意識や注意と同じものではなく、モデル内の数値計算を表す用語です。

参考：Vaswani et al.: Attention Is All You Need

使う場面

文章中の「それ」を処理するとき、同じ文章の他の語の情報を組み合わせる。

確認ポイント

必ず文全体を参照するわけではありません。文章生成では、未来の語を見ないよう参照先を制限することがあります。

参考：Vaswani et al.: Attention Is All You Need

使う場面

文章をエンコーダーで表現に変え、その表現から問い合わせの種類を分類する。

確認ポイント

ここではモデル内の役割を指し、暗号化する装置という意味ではありません。単独で使う構成もあります。

参考：Hugging Face: Transformer Architectures

使う場面

翻訳モデルで、読み取った原文の表現から訳文を順に作る。

確認ポイント

別のエンコーダーを持たない構成もあります。生成した内容の正しさを保証する部品ではありません。

参考：Hugging Face: Transformer Architectures

使う場面

言語モデルが、書きかけの文に続くトークンを一つずつ生成する。

確認ポイント

一度出した誤りが後続の出力へ影響することがあります。すべての言語モデルが同じ生成方式とは限りません。

参考：Hugging Face: How Transformers solve tasks

使う場面

学習で重みが更新されることと、プロンプトだけを変えることの違いを理解する。

確認ポイント

パラメータ数の多さだけでは性能を比較できません。学習率などの学習設定はハイパーパラメータと区別します。

参考：Google: Nodes and hidden layers / Google: Linear regression: Hyperparameters

使う場面

同じ日本語の文でも、使うモデルによってトークン数が変わる理由を確認する。

確認ポイント

単語単位や一文字単位とは限りません。モデルに対応するトークナイザーを使う必要があります。

参考：Hugging Face: Tokenization algorithms

使う場面

珍しい語を複数の既知の部品に分け、語彙にない語も表現しやすくする。

確認ポイント

語根や接尾辞など、言語学上の意味の切れ目と必ず一致するわけではありません。

参考：Hugging Face: Tokenization algorithms

使う場面

正解付きの商品画像を使い、分類の誤りが減るようモデルの重みを更新する。

確認ポイント

会話へ資料を追加するだけでは、通常はモデルの重みを更新する学習にはなりません。学習済みモデルを使う処理は推論です。

参考：Google: Supervised Learning

使う場面

自分のアプリやツールにAIを組み込むとき。

確認ポイント

利用には料金や上限が設定されている場合が多く、事前に公式の条件を確認すると安心です。

使う場面

外部ツールやコードからAIに接続するとき。

確認ポイント

コードの公開場所や共有画面に載せないようにします。漏れた場合は、そのキーを無効化して作り直します。

使う場面

長文を扱うときや、料金の仕組みを理解するとき。

確認ポイント

文字数や単語数と一対一では対応しません。同じ文章でもモデルの分割方式で数が変わり、画像や音声の数え方も別に確認します。

使う場面

長い文章や資料をまとめて読ませたいとき。

確認ポイント

入力・出力・思考用トークンをどう数えるかはモデルによって異なります。上限が大きくても、全情報を正確に使えるとは限りません。

使う場面

短時間に多く使ってエラーが出たとき。

確認ポイント

RPM・TPMなど制限の種類とリセット条件を確認し、再試行間隔や処理量を調整します。

使う場面

「これ以上使えません」と表示されたとき。

確認ポイント

無料枠と有料枠で上限が異なる場合が多く、公式の表示を確認すると判断しやすくなります。

使う場面

まず試してみたいとき。

確認ポイント

使える機能や回数が制限される場合があり、内容は変更されることもあるため最新情報の確認が安全です。

使う場面

作った文章や画像を業務で使いたいとき。

確認ポイント

サービスの利用条件と、生成物に含まれる第三者の著作物・商標・肖像などの権利は分けて確認します。利用許可だけで、すべての権利処理が済むわけではありません。

使う場面

速度重視か精度重視かで迷うとき。

確認ポイント

同じ課題で出力を比べ、品質・速度・費用・扱える情報の条件を確認します。上位の名称だけで適性は決まりません。

使う場面

画像生成などで「残り回数」を意識するとき。

確認ポイント

1クレジットの意味はサービスごとに異なります。消費条件・有効期限・追加購入時の扱いを確認します。

使う場面

最新情報を調べ、複数の出典を比較したいとき。

確認ポイント

回答文だけでなく、引用先が主張を支えているか、公開日や一次情報まで確認することが重要です。

使う場面

モデルやAPIの体感速度、待ち時間を比較するとき。

確認ポイント

最初の表示までと完了まででは意味が異なり、モデル・入力の長さ・接続処理など複数の要因で変わります。

使う場面

APIや画像生成の利用費用を見積もるとき。

確認ポイント

入力・出力・画像・保存など、何に課金されるかを確認します。予算通知と利用を停止する上限は別の場合があります。

使う場面

APIの料金明細や、長い回答の費用を確認するとき。

確認ポイント

入力と出力で単価が異なる場合があります。内部の思考用トークンや、キャッシュ利用分の扱いも確認します。

使う場面

同じ長い資料や共通の指示を、何度もモデルへ渡すとき。

確認ポイント

前回の回答をそのまま返す仕組みとは限りません。適用条件・保持時間・保存料金・割引の対象を確認します。

参考：Google：コンテキストキャッシュ

使う場面

長い回答を待ち切る前に、冒頭から画面へ表示するチャット画面に使います。

確認ポイント

表示を早く始められても、生成全体が速くなるとは限りません。途中の切断やエラーと正常終了を区別します。

参考：OpenAI API: Streaming API responses

使う場面

多くの利用者が同時にAIを使うとき、サーバー全体がどれだけ処理できるかを比較するときに使います。

確認ポイント

1件の待ち時間を表すレイテンシとは別です。入力や出力の長さ、同時利用数、測定単位をそろえて比較します。

参考：NVIDIA: GenAI-Perf metrics

使う場面

チャット画面で回答が表示され始めるまでの待ち時間を調べるときに使います。

確認ポイント

回答全体が完成する時間とは別です。測定ツールによって最初の応答を数える条件が異なるため、比較前に定義を確認します。

参考：NVIDIA: GenAI-Perf metrics

使う場面

単発の回答でなく、一連の作業を任せたいとき。

確認ポイント

自動で動く範囲が広いほど便利な一方、想定外の動作もあり得るため確認しながら使うと安心です。

参考：Anthropic：AIエージェントの設計

使う場面

自社資料や最新情報にもとづいた回答が欲しいとき。

確認ポイント

参照元の質が回答の質を左右するため、元データの正確さが重要になります。

使う場面

AIに外部サービスを操作させる構成を理解するとき。

確認ポイント

接続仕様そのものが安全性を保証するわけではないため、対応状況に加えて権限・認証・実行前確認を設計します。

参考：MCP公式ドキュメント

使う場面

開発系AIツールを端末から動かすとき。

確認ポイント

操作は強力ですが、コマンドの意味を理解してから使うと事故を防ぎやすくなります。

使う場面

AI支援でコードを書く環境を選ぶとき。

確認ポイント

AI連携の方式はツールで異なるため、目的に合うものを選ぶと作業がスムーズです。

使う場面

開発系AIツールと連携するとき。

確認ポイント

公開・非公開の設定を誤ると情報が見える場合があるため、権限の確認が大切です。

使う場面

自分のPCでツールやモデルを動かす構成を考えるとき。

確認ポイント

PC上のアプリでも外部APIへデータを送る場合があります。「ローカルで起動」と「外部通信なし」は分けて確認します。

使う場面

高い処理能力を手軽に使いたいとき。

確認ポイント

手軽な反面、料金やデータの扱いは提供元の条件に従うため、規約の確認が役立ちます。

使う場面

定型作業を減らしたいとき。

確認ポイント

任せきりにせず、結果を点検する手順を残すと品質を保ちやすくなります。

使う場面

AIを使った制作手順を整理するとき。

確認ポイント

流れを見える形にすると、どこを改善すべきか判断しやすくなります。

使う場面

決まった形式や専門領域へ、モデルの振る舞い自体を寄せたいとき。

確認ポイント

外部資料を都度参照するRAGとは役割が異なり、学習データの品質・費用・評価設計が結果を左右します。

使う場面

計算資源や保存容量を抑えながら、用途別の調整を試したいとき。

確認ポイント

低コストでもデータ品質と評価は必要で、元モデルの知識を自動で最新化する仕組みではありません。

使う場面

意味検索、類似文書検索、RAGの検索部分を理解するとき。

確認ポイント

利用するモデルや分割方法で検索結果が変わり、ベクトル化しただけで正確な回答が保証されるわけではありません。

使う場面

RAGやAI検索が、関連する文書をどのように取り出すか理解するとき。

確認ポイント

検索品質はEmbedding、文書の分割、メタデータ、更新方法の組み合わせで決まります。

使う場面

検索、予約、データ取得など外部の処理をAIから呼び分けたいとき。

確認ポイント

多くの場合、実際に処理を実行するのはアプリ側です。引数の検証と、重要操作の確認を別に設けます。

使う場面

回答をそのまま画面表示や後続処理へ渡したいとき。

確認ポイント

形式が合うことと内容が正しいことは別です。値の範囲・事実性・権限はアプリ側でも確認します。

使う場面

資料作成やコードレビューなどの進め方を、繰り返し使いたいとき。

確認ポイント

Agent Skills形式ではSKILL.mdに説明や指示を記述します。外部のスキルは、実行するコードや必要な権限も確認します。

参考：Agent Skills公式仕様

使う場面

保存した資料の検索や、外部サービスの操作をAIに組み合わせるとき。

確認ポイント

読める情報と実行できる操作は、連携先と許可した権限で決まります。接続を解除する方法も確認します。

使う場面

専用APIがない画面で、一連の操作を進めたいとき。

確認ポイント

画面の見間違いや操作ミスに備え、対象のアカウントと変更内容を確認します。送信・購入などは実行前に点検します。

使う場面

RAGで資料をどの単位で検索するか考えるとき。

確認ポイント

小さすぎると前後関係が失われ、大きすぎると不要な情報が増えます。見出しや意味の切れ目も使って分けます。

使う場面

検索結果の上位に、回答の根拠になる資料を集めたいとき。

確認ポイント

最初の検索で拾えなかった資料は、並べ替えだけでは取り戻せません。検索と再評価の両方を確認します。

使う場面

独立した作業を分担し、結果をまとめたいとき。

確認ポイント

分担を増やすと調整や費用も増えます。渡す情報・権限・完了条件を決め、結果の食い違いを確認します。

参考：Anthropic：コンテキストの設計

使う場面

「休暇の残りを知りたい」という質問から、有給休暇の残日数を扱う社内規程を探すときに使います。

確認ポイント

意味が近くても質問の答えとは限りません。製品によって検索や順位付けの実装は異なります。

参考：Elastic: Semantic search for text

使う場面

製品型番の一致と、質問内容に近い説明文の両方を拾うFAQ検索に使います。

確認ポイント

組み合わせただけで精度が上がるとは限りません。結果の統合方法や重みを実際の質問で確かめます。

参考：Microsoft: Create a hybrid query

使う場面

AIが参照する社内資料から、特定の製品名や規約の条文を探すときに使います。

確認ポイント

「全文」は文書全体を対象にする意味です。表記揺れや言い換えへの対応は検索の設定によります。

参考：Elastic: How full-text search works

使う場面

キーワード検索で見つかった資料を、質問に関係しそうな順に並べるときに使います。

確認ポイント

点数は正答確率ではありません。文書集合や設定が異なる検索の点数を、そのまま比較しないようにします。

参考：Elastic: How full-text search works

使う場面

大量の資料を毎回最初から読まず、検索語を含む文書へ素早くたどり着くために使います。

確認ポイント

文章の意味を直接理解する仕組みではありません。単語への分け方や表記の扱いが検索結果に影響します。

参考：Elastic: How full-text search works

使う場面

質問と資料を埋め込み表現に変換し、内容が近い文書を候補として取り出すときに使います。

確認ポイント

同じ次元数でも、異なる埋め込みモデルの値をそのまま比較できるとは限りません。

参考：Elastic: Vector search in Elasticsearch

使う場面

質問と文書の埋め込み表現を比べ、向きが近い文書を探すときに使います。

確認ポイント

値の大きさは事実の正しさを示しません。コサイン距離は通常「1から類似度を引いた値」で、大小の向きが逆です。

参考：Faiss: MetricType and distances

使う場面

埋め込みモデルに合う比較方法として、内積で文書候補の順位を計算するときに使います。

確認ポイント

ベクトルの長さにも影響されます。両方を長さ1にそろえた場合はコサイン類似度と一致します。

参考：Faiss: MetricType and distances

使う場面

数値で表した画像や文書の特徴を比較し、距離の小さい候補を探すときに使います。

確認ポイント

各成分の尺度やベクトルの長さに影響されます。実装が距離そのものと距離の二乗のどちらを返すかも確認します。

参考：Faiss: MetricType and distances

使う場面

数百万件の埋め込み表現から、応答時間を抑えて似た資料を取り出すときに使います。

確認ポイント

最も近い候補を必ず見つける保証はなく、速度と見落としの少なさを比べます。ANNは人工ニューラルネットワークの略にも使われるため、文脈を確認します。

参考：pgvector: Indexing

使う場面

文書検索のベクトル索引を作り、全件比較より少ない探索で候補を探すときに使います。

確認ポイント

近似探索なので見落としがあり得ます。探索量やつながりの数を増やすと、精度と引き換えに計算量やメモリが増えます。

参考：Malkov and Yashunin: HNSW paper / pgvector: Indexing

使う場面

大量のベクトルから、一部のグループだけを調べて検索時間を短くするときに使います。

確認ポイント

調べるグループ数が少ないほど候補を見落としやすくなります。IVFFlatはIVFの一種で、IVF全体の別名ではありません。

参考：Faiss: Faiss indexes

使う場面

社内RAGで「今年改訂された営業部の資料」だけを回答の参考にするときに使います。

確認ポイント

検索の前後どちらで絞るかで結果数や見落としが変わります。属性による絞り込みだけをアクセス権の代わりにしない設計が必要です。

参考：Microsoft: Vector query filters

使う場面

会話の「その返品条件は？」を、商品名を補った具体的な検索文に変えるときに使います。

確認ポイント

書き換えで元の条件や型番が落ちることがあります。検索文と元の質問の意図が合うか確認します。

参考：Microsoft: Rewrite queries with semantic ranker

使う場面

「PCの廃棄」に「パソコンの処分」などの表現を加えて社内手順を探すときに使います。

確認ポイント

候補が増える一方、無関係な資料も混ざり得ます。質問全体を組み直すクエリ書き換えの一部として使われることもあります。

参考：Google Cloud: RAGs powered by Google Search technology, Part 1

使う場面

キーワード検索とベクトル検索の異なる点数を直接比べず、順位から結果をまとめるときに使います。

確認ポイント

元の点数差をそのまま保つ方法ではありません。文章を読んで関連度を評価し直すリランキングとも区別します。

参考：Microsoft: Relevance scoring using RRF

使う場面

段落の境目で説明が切れても前後関係を拾えるよう、文末の数文を次のチャンクにも入れるときに使います。

確認ポイント

重なりを増やすと保存量や処理量も増えます。検索結果に同じ内容が何度も入らないか確認します。

参考：Microsoft: Chunk large documents for RAG and vector search

使う場面

複数の話題を含む議事録を、検索しやすい話題ごとのチャンクに分けるときに使います。

確認ポイント

分割方法には複数の実装があります。意味のまとまりを保っても、入力上限に収まる長さかを別に確認します。

参考：Microsoft: Chunk large documents for RAG and vector search

使う場面

規程の一文を検索の手掛かりにし、その前提や例外を含む節全体をAIに読ませるときに使います。

確認ポイント

親は元文書全体の場合も、大きめの分割片の場合もあります。親が大きすぎると余分な情報や入力量が増えます。

参考：LangChain: ParentDocumentRetriever

使う場面

複数の報告書に登場する組織の関係や、資料全体に共通する話題を調べるときに使います。

確認ポイント

Microsoftの同名実装では関係抽出や集団の要約を利用します。一般的な方式名としても使われ、グラフ作成の費用や抽出誤りに注意が必要です。

参考：Microsoft GraphRAG: Indexing overview / Microsoft GraphRAG: Query overview

使う場面

社内PDFを取り込み、質問に答えるRAGが検索できる状態に整えるときに使います。

確認ポイント

資料を保存しただけでは検索に反映されない構成もあります。取り込みの失敗や更新の遅れを確認します。

参考：Microsoft: Indexer overview

使う場面

毎日更新される社内資料を、全件の再処理を避けながらRAGに反映するときに使います。

確認ポイント

変更を検出できる仕組みが必要です。削除された資料も索引から消えるかを別に確認します。

参考：Microsoft: Index data from Azure SQL Database

使う場面

調査、執筆、確認の担当を組み合わせ、一つのレポートを作る仕組みを設計するときに使います。

確認ポイント

すべてをAIの判断に任せる必要はありません。固定した処理はコードで管理し、判断が必要な部分にAIを使う構成もあります。

参考：OpenAI Agents SDK: Agent orchestration

使う場面

資料調査と計算の担当を分け、最後に結果をまとめるAIアプリを作るときに使います。

確認ポイント

人数を増やすだけで品質が上がるとは限りません。連絡や情報共有の負担、処理費用、担当間の食い違いも増えます。

参考：LangChain: Multi-agent

使う場面

問い合わせの内容が技術相談だと分かった時点で、受付担当から技術担当へ対応を渡すときに使います。

確認ポイント

この項目はエージェント間の引き継ぎを指します。補助担当の結果を元の担当へ返すツール呼び出しとは制御の流れが異なります。

参考：OpenAI Agents SDK: Handoffs

使う場面

質問を「請求」「操作方法」「不具合」に分類し、それぞれに合う担当へ渡すときに使います。

確認ポイント

振り分けを誤ると、その後の処理が適切でも答えを外します。どの分類にも合わない入力の行き先も決めます。

参考：Anthropic: Building effective agents

使う場面

最初に記事の構成を作り、次に本文を書き、最後に表現を整える処理で使います。

確認ポイント

前の段階の誤りが後へ伝わります。途中結果を点検する工程を入れ、呼び出し回数による待ち時間も確認します。

参考：Anthropic: Building effective agents

使う場面

複数の資料を別々に要約してからまとめ、調査の待ち時間を短くするときに使います。

確認ポイント

前の結果が必要な処理はそのまま並列化できません。同時呼び出しの増加でレート制限や費用にも影響します。

参考：Anthropic: Building effective agents

使う場面

コードを修正し、テスト結果を読み、失敗箇所を直して再テストするエージェントに使います。

確認ポイント

完了判定や回数・時間の上限がないと、同じ作業を繰り返すことがあります。結果が改善しているかも確認します。

参考：OpenAI Agents SDK: Running agents

使う場面

長いエージェント作業を人の承認待ちで止め、承認後に続きから再開するときに使います。

確認ポイント

モデルの重みを保存する学習チェックポイントとは別です。再開時に送信や更新の操作を二重実行しない設計も必要です。

参考：LangChain: Persistence

使う場面

長時間の調査で、重要な結論と未完了の作業を残しながら会話を続けるときに使います。

確認ポイント

要約から条件や細部が抜けることがあります。履歴を短くする処理であり、モデル自体の記憶容量が増えるわけではありません。

参考：Anthropic: Compaction overview

使う場面

検索ツールに必要な検索語や件数をAIが正しい形で渡せるようにするときに使います。

確認ポイント

型が正しくても、値の意味や操作の許可まで正しいとは限りません。実行側で値の検査と権限確認を行います。

参考：MCP specification: Tools

使う場面

チャットアプリや開発エディタが、複数のMCP接続をまとめて扱う構成を理解するときに使います。

確認ポイント

ホストは利用者が使うアプリ側の役割です。機能を提供するMCPサーバーや、接続を受け持つクライアントと区別します。

参考：MCP: Architecture overview

使う場面

一つのAIアプリからファイル用と検索用のサーバーへ、それぞれ接続するときに使います。

確認ポイント

利用者向けアプリ全体ではなく、接続を担う構成要素を指します。接続できても、全機能を使えるとは限りません。

参考：MCP: Architecture overview

使う場面

社内データベースの検索機能を、複数のAIアプリから共通の方法で使えるようにするときに使います。

確認ポイント

「サーバー」は役割の名前で、自分のPC上でも外部の環境でも動きます。接続前に提供元と扱う権限を確認します。

参考：MCP: Architecture overview

使う場面

Python用SDKを使い、AIへのリクエストや応答の読み取りを少ないコードで実装するときに使います。

確認ポイント

APIは機能を呼び出す窓口で、SDKはその利用を助ける道具です。対応言語やバージョンを確認します。

参考：AWS: What is an SDK?

使う場面

文章生成用と埋め込み生成用の送信先を、APIの説明書に合わせて設定するときに使います。

確認ポイント

Web APIでは通常URLで表します。同じ提供元でも機能、地域、APIの版などで接続先が異なります。

参考：AWS: Service endpoints

使う場面

AIの出力に「商品名は文字列、個数は整数」という形の条件を定めるときに使います。

確認ポイント

JSONとして読めることと、スキーマに合うことは別です。形式が合っても内容の正しさは別に確かめます。

参考：JSON Schema: What is JSON Schema?

使う場面

AIの生成した文字列の断片や進行状況を、届いた順に画面へ反映するときに使います。

確認ポイント

この接続でのイベント送信はサーバーから受け手への一方向です。利用者の新しい入力を送るには別のリクエストなどを使います。

参考：MDN: Using server-sent events

使う場面

大量の文章処理が終わった通知を受け、結果を取り込む次の処理を始めるときに使います。

確認ポイント

通知の署名などで送信元を確かめます。重複通知や再送があり得るため、同じ結果を二重処理しない設計が必要です。

参考：OpenAI API: Webhooks

使う場面

すぐに結果が要らない大量の問い合わせ分類や文書要約を、まとめて実行するときに使います。

確認ポイント

AIサービスでは非同期で結果を回収する方式もあります。学習時のバッチサイズとは文脈が異なり、全件成功とも限りません。

参考：OpenAI API: Batch API

使う場面

AIへ長い資料の分析を依頼し、画面の操作を止めずに完了後の結果を表示するときに使います。

確認ポイント

非同期にしても処理自体が必ず速くなるわけではありません。完了、失敗、取り消しの扱いを決めます。

参考：MDN: Introducing asynchronous JavaScript

使う場面

AIの長い分析ジョブが「実行中」か「完了」かを、間隔を空けて確認するときに使います。

確認ポイント

短い間隔で問い合わせすぎると負荷や呼び出し回数が増えます。完了だけでなく失敗や中止でも確認を終えるようにします。

参考：OpenAI API: Background mode

使う場面

応答が届かなかった予約登録などを再試行しても、同じ予約が二重に作られないようにするときに使います。

確認ポイント

同じ文章を再生成して同じ答えになる、という意味ではありません。重複を識別するキーの有効期間や対象はAPIごとに確認します。

参考：AWS: Making retries safe with idempotent APIs

使う場面

RAGの回答が遅い原因を、検索、並べ替え、文章生成のどの工程にあるか調べるときに使います。

確認ポイント

記録対象や間引き方によって見える範囲が変わります。入力やツール結果に個人情報が含まれる場合は保存範囲を絞ります。

参考：OpenTelemetry: Traces

使う場面

AIアプリの遅延、失敗率、利用量を関連付け、どこで問題が起きているか調べるときに使います。

確認ポイント

記録を大量に集めるだけでは十分ではありません。要求ごとに情報を結び付け、必要な原因を調べられる設計にします。

参考：OpenTelemetry: Observability primer

使う場面

AIモデルを呼ぶアプリを、開発用PCと運用サーバーで近い条件で動かすときに使います。

確認ポイント

配布用のひな型はコンテナイメージと呼びます。依存関係をまとめても、権限やデータの保存先は別に設計します。

参考：Kubernetes: Containers

使う場面

AIアプリへのアクセスが増えた際に稼働台数を増やし、減ったら台数を戻す運用で使います。

確認ポイント

台数を増やす横方向と、1台の資源を増やす縦方向があります。起動までの時間や費用の上限も考慮します。

参考：Kubernetes: Horizontal Pod Autoscaling

使う場面

AIアプリの入口で要求を複数の稼働先へ振り分け、混雑や一部の停止に備えるときに使います。

確認ポイント

単純な均等割りだけでなく、稼働状態などで分ける方式もあります。振り分けるだけで処理資源が増えるわけではありません。

参考：AWS: What is Elastic Load Balancing?

使う場面

AIモデルの読み込みが済むまで要求を回さず、準備ができたら受付を始める運用で使います。

確認ポイント

生きているかの検査と、要求を受けられるかの検査は役割が違います。合格してもAIの回答内容が正しい保証にはなりません。

参考：Kubernetes: Liveness, Readiness, and Startup Probes

使う場面

新しいモデルやプロンプトを一部の利用者で試し、品質や遅延に問題がないか見てから広げるときに使います。

確認ポイント

判定基準と元に戻す手順を先に決めます。一部で問題が出なかったことだけで、全利用者への安全性を断定しません。

参考：Google SRE Workbook: Canarying releases

使う場面

AIがコードを修正した後に、既存の検索や保存機能が壊れていないか確認するときに使います。

確認ポイント

新機能の確認だけでは足りません。AIの文章出力に揺れがある場合は、文字の完全一致以外の評価基準も設けます。

参考：Microsoft: Types of tests that implementation projects use

使う場面

AIが作った修正案に対してテストを自動実行し、合格したものを決めた手順で配布するときに使います。

確認ポイント

CDは継続的デリバリーと継続的デプロイの両方を指します。本番公開に人の承認を挟むかどうかを確認します。

参考：GitHub: What is CI/CD?

使う場面

RAG、MCP、Web閲覧、外部ツール操作を安全に設計するとき。

確認ポイント

入力の検査だけでなく、最小権限、人の確認、秘密情報の分離、ログ確認を組み合わせる必要があります。

使う場面

個人情報や社内情報を扱うとき、APIや外部アプリを連携するとき。

確認ポイント

一つの設定で完結せず、入力情報・認証情報・権限・請求・ログを分けて確認することが基本です。

使う場面

公開サービスや自動処理で、危険な内容や想定外の操作を減らしたいとき。

確認ポイント

一つのフィルターだけに頼らず、最小権限・入力検査・人の確認・監視を重ねて設計します。

使う場面

ファイルや機能にアクセスできないとき。

確認ポイント

公開範囲や共有設定を誤ると見えない／見えすぎる場合があるため、確認が大切です。

使う場面

AIが生成したコードや、外部のツールを実行するとき。

確認ポイント

ファイル・通信・権限の制限範囲を確認します。名前がサンドボックスでも、すべての操作が無害になるわけではありません。

使う場面

AIにファイルや外部サービスを接続するとき。

確認ポイント

読むだけで足りるなら、編集や削除の権限まで与えないようにします。対象の範囲と利用期間も絞ります。

参考：NIST：最小権限

使う場面

送信・公開・購入・削除など、影響の大きい操作を任せるとき。

確認ポイント

承認する人が、対象・内容・影響を判断できる情報を示します。確認ボタンがあるだけで品質が保証されるわけではありません。

参考：Anthropic：AIエージェントの設計

使う場面

AIが何を目指し、何を避けるように作られているか考えるとき。

確認ポイント

誰の目標を、どの場面で優先するかも論点です。感じのよい回答と、正しく役立つ回答は同じとは限りません。

使う場面

相談や判断をAIに頼み、賛成ばかり返ってくると感じるとき。

確認ポイント

反証や異なる見方も尋ね、事実は別の情報源で確認します。「同意されたこと」を正しさの根拠にしないようにします。

参考：Anthropic：迎合に関する研究

使う場面

対話AIの導入前に、許可された評価環境で安全制約への耐性を確認する。

確認ポイント

外部文書の命令でAIを誘導するプロンプトインジェクションと重なることはありますが、指す範囲は同じではありません。

参考：NIST AI 600-1: Generative Artificial Intelligence Profile

使う場面

外部から取得する学習データの出所と変更履歴を確認し、改ざんの兆候を探す。

確認ポイント

偶然のデータ誤りとは区別します。評価用データが学習に混ざるデータリークとも別の問題です。

参考：OWASP LLM04:2025 Data and Model Poisoning

使う場面

配布モデルの採用時に、入手元の確認と想定外の条件での評価を行う。

確認ポイント

通常のテストの正答率が高くても、仕掛けがない証明にはなりません。

参考：BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain

使う場面

画像認識の評価で、人には似て見える画像への変更に結果が左右されないか調べる。

確認ポイント

小さな見た目の変化でも判断が変わる場合があります。単なる画質劣化や自然な誤認識と区別します。

参考：Explaining and Harnessing Adversarial Examples

使う場面

AIをAPIで公開する前に、応答として渡す情報の範囲や不審な利用の監視を検討する。

確認ポイント

必ず元の重みをそのまま取り出す攻撃とは限りません。学習データの内容を推定する攻撃とは目的が違います。

参考：USENIX: Stealing Machine Learning Models via Prediction APIs

使う場面

個人の記録で学習するAIの公開前に、学習への参加が漏れるリスクを評価する。

確認ポイント

記録の内容を全部復元する攻撃ではありません。含まれていた事実だけでも機微な情報になる場合があります。

参考：Membership Inference Attacks against Machine Learning Models

使う場面

個人情報を扱うモデルで、公開する予測結果から何が推測され得るか確認する。

確認ポイント

推定結果が元のデータそのものや、実在する個人の正確な情報とは限りません。

参考：Model Inversion Attacks that Exploit Confidence Information and Basic Countermeasures

使う場面

統計公開やAI学習にノイズを加え、個人の影響を抑える設計に使う。

確認ポイント

保護の強さは設定や実装に依存します。ノイズを足すだけで差分プライバシーを満たすとは限りません。

参考：NIST SP 800-226: Guidelines for Evaluating Differential Privacy Guarantees

使う場面

分析用データで細かな属性をまとめ、個人が再識別されるリスクを確認する。

確認ポイント

名前を消すだけでは十分とは限りません。法令上の「匿名加工情報」などの要件とは分けて確認します。

参考：ICO: What is personal data?

使う場面

氏名を参加者IDへ置き換え、対応表は分析データと分けて管理する。

確認ポイント

追加情報によって本人と結び付く点で、匿名化と異なります。法令上の「仮名加工情報」と同義とは限りません。

参考：ICO: What is personal data?

使う場面

公開前の社内AIで、情報漏れや不適切な回答が起きる場面を許可された範囲で検証する。

確認ポイント

目的・対象・実施範囲を決めて行います。問題が見つからなくても、あらゆる状況で安全だとは断定できません。

参考：Red Teaming Language Models to Reduce Harms: Methods, Scaling Behaviors, and Lessons Learned

使う場面

投稿のうち、暴言の可能性があるものをAIで分類し、人が確認する候補にする。

確認ポイント

自動判定には見逃しと誤検知があります。引用や文脈を考慮し、必要に応じて人が再確認します。

参考：Microsoft Learn: What is Azure AI Content Safety?

使う場面

画像認識が特定の撮影条件や利用者層で失敗しやすくないか、結果を分けて調べる。

確認ポイント

偏りは学習データだけから生まれるものではありません。平均性能だけでは、特定の集団への不利益を見落とす場合があります。

参考：NIST SP 1270: Towards a Standard for Identifying and Managing Bias in Artificial Intelligence

使う場面

音声認識の誤りが特定の話し方に偏っていないか、利用者への影響も含めて調べる。

確認ポイント

公平性の基準は用途や文脈によって異なります。一つの数値がそろうだけで、公平だと保証することはできません。

参考：Fairlearn: Fairness in Machine Learning

使う場面

分類結果に影響した入力項目を示し、担当者が妥当性を確認できるようにする。

確認ポイント

説明が分かりやすいことと、判断が正しいことは別です。説明が実際の処理に忠実かも確認します。

参考：NIST IR 8312: Four Principles of Explainable Artificial Intelligence

使う場面

採用候補のモデルについて、得意な言語や使うべきでない場面を確認する。

確認ポイント

記載の評価条件と自分の用途を照合します。カードがあるだけで性能や安全性が保証されるわけではありません。

参考：Model Cards for Model Reporting

使う場面

学習用画像を選ぶ際に、撮影条件や含まれる対象の偏りを確認する。

確認ポイント

モデルそのものを説明するモデルカードとは対象が違います。説明文書と実データの状態を照合することも必要です。

参考：Datasheets for Datasets

使う場面

社内AIの責任者、承認が必要な用途、問題発生時の連絡先を定める。

確認ポイント

利用ルールを書くだけで完了ではありません。運用の確認や更新が必要で、特定の法律への適合を保証する言葉ではありません。

参考：NIST AI RMF Playbook: Govern

使う場面

問い合わせAIの誤回答や情報漏れを想定し、公開前に対策の優先順位を決める。

確認ポイント

モデルの正答率だけでは評価できません。利用者、接続先、運用方法が変われば、リスクも見直します。

参考：NIST AI RMF Playbook: Map

使う場面

AIの集計結果を見た人が、元の表の不一致を見逃していないか確認する。

確認ポイント

AIが利用者へ同意しすぎる迎合とは別で、人の側に起きる偏りです。重要な判断では元の情報も確認します。

参考：NIST AI 600-1: Generative Artificial Intelligence Profile

使う場面

AIへ渡す問い合わせ文から、回答に不要な連絡先を取り除く。

確認ポイント

自動検出は漏れることがあります。見た目を黒くするだけで情報が残る形式もあるため、出力データを確認します。

参考：Google Cloud: Redacting sensitive data from text

使う場面

文面の要約だけなら、不要な住所や顧客番号をAIへ渡さないようにする。

確認ポイント

単にデータを少なくすればよいわけではありません。目的に必要な情報は確保し、不要な情報を減らします。

参考：ICO: Principle (c): Data minimisation

使う場面

出所不明の発言動画について、元の公開先や別の記録を確認するきっかけにする。

確認ポイント

見た目や声が自然なだけでは本物と判断できません。検出ツールの判定も完全ではないため、出所を併せて確認します。

参考：NIST AI 100-4: Reducing Risks Posed by Synthetic Content

使う場面

画像の作成者や編集履歴を確認し、利用や検証の手掛かりにする。

確認ポイント

来歴が確認できても、写っている出来事が事実だとは限りません。C2PAは来歴を扱う技術標準の一つです。

参考：C2PA and Content Credentials Explainer 2.2

使う場面

AIへ渡した情報が、どこに・いつまで残るかを確認するとき。

確認ポイント

学習に使われないことと、保存されないことは別です。保持期間、削除の対象・時期、例外をサービスごとに確認します。

使う場面

個人向けAIサービスのデータ利用設定を確認するとき。

確認ポイント

対象となる内容や適用時点はサービスごとに異なります。履歴・メモリの削除とは別で、フィードバック送信などに別条件がある場合もあります。

使う場面

AIへメールやファイルの連携を許可する前に、できる操作の範囲を確認するとき。

確認ポイント

スコープ名と意味はサービスが定めます。閲覧と変更・送信などの違いを確認し、必要な範囲だけを許可します。

使う場面

モデルやプロンプトを変えたとき、良くなったか悪化したかを比較するとき。

確認ポイント

平均点だけでなく、実際に失敗すると困るケースと、変更前からの劣化を拾える構成にします。

使う場面

「性能が上がった」という発表やランキングを読むとき。

確認ポイント

何を測る課題か、条件が揃っているかを見ます。高得点でも、自分の仕事で同じ成果が出るとは限りません。

使う場面

新しい手法の、どの工夫が役立ったのかを確認するとき。

確認ポイント

複数の条件を同時に変えると原因を分けにくくなります。比較条件と、結果のばらつきも確認します。

参考：Google ML用語集

使う場面

新しいモデルや手順の効果を説明するとき。

確認ポイント

弱い比較相手だけでは、実用上の価値は分かりません。現在使っている方法や、単純な方法とも比べます。

参考：Google ML用語集

使う場面

モデルの評価結果が不自然によい、実運用では再現しないとき。

確認ポイント

学習用と評価用を分け、前処理や設定の選択でも評価データを先に見ないようにします。情報漏洩という一般的な意味とは文脈が異なります。

参考：scikit-learn：評価時の注意点

使う場面

学習時の成績はよいのに、新しい例で失敗するとき。

確認ポイント

未使用のデータで確かめ、簡単な方法とも比べます。同じ評価問題を繰り返し見て調整すると、評価にも偏りが生まれます。

使う場面

論文の結果やAIの検証記事を、自分でも試したいとき。

確認ポイント

モデルの版・日付・入力・設定・評価方法を残します。乱数のある処理では、一度の一致だけでなく結果のばらつきも見ます。

参考：scikit-learn：評価時の注意点

使う場面

モデルが知識や言語のパターンをどのように身につけるか知りたいとき。

確認ポイント

学習に使ったことと、正確に記憶・回答できることは別です。新しい資料を渡すRAGとも区別します。

使う場面

同じ基盤から作られたモデルでも、応答の仕方が違う理由を知りたいとき。

確認ポイント

指示データによる調整やフィードバックを使う学習など、複数の方法があります。すべてが同じ手順を使うわけではありません。

使う場面

モデル仕様を読むとき、全パラメータ数と一回の処理で使うパラメータ数を分けて確認する。

確認ポイント

「専門家」は人や別々の会話エージェントではなく、モデル内部の計算部分です。全てを毎回動かすとは限りません。

参考：Shazeer et al.: The Sparsely-Gated Mixture-of-Experts Layer

使う場面

ReLUのような関数を層の間に入れ、単純な直線では表せない関係を学習する。

確認ポイント

層を重ねても、線形な計算だけでは表現できる関係が限られます。関数の選択は学習の進み方にも影響します。

参考：Google: Activation functions

使う場面

次の語の候補に付いたスコアを、選択に使う確率の形へ変換する。

確認ポイント

確率の形に変換しても、その数値が現実の正解率と一致するとは限りません。

参考：PyTorch: Softmax

使う場面

トークナイザーの説明でBPEと書かれていたら、頻出する並びをまとめる方式だと理解する。

確認ポイント

文字から始める方式とバイトから始める方式があります。同じBPEでも語彙や学習データで分割結果は変わります。

参考：Hugging Face: Tokenization algorithms

使う場面

配達時間の予測と実測の差を数値化し、その値を減らす方向に学習する。

確認ポイント

損失が小さくても、利用者が求める品質を満たすとは限りません。何を誤りとして数えるかを確認します。

参考：Google: Linear regression: Loss

使う場面

予測の誤りを減らすため、傾きと学習率から重みの修正量を決める。

確認ポイント

一回の更新で最良の答えが見つかるわけではありません。学習率や初期値によって進み方が変わります。

参考：Google: Gradient descent

使う場面

多層のモデルで、どの重みをどちらへ変えると損失が減るかを計算する。

確認ポイント

主な役割は勾配を求めることで、実際の重みの更新規則はオプティマイザーが決めます。

参考：Google: Training using backpropagation / PyTorch: Neural Networks

使う場面

同じモデルの学習でSGDやAdamを選び、検証データで結果を比較する。

確認ポイント

どの手法でも常に最良とは限りません。学習率などの設定と組み合わせて確かめます。

参考：PyTorch: Optimizing Model Parameters

使う場面

学習中の損失が大きく上下するとき、学習率が高すぎないか調べる。

確認ポイント

高いほど速くよいモデルになるわけではありません。低すぎると学習が進みにくく、高すぎると不安定になることがあります。

参考：Google: Linear regression: Hyperparameters

使う場面

画像を32枚ずつまとめてモデルに入力し、学習時のメモリ使用量を調整する。

確認ポイント

バッチの個数ではなく、一つのバッチに入る件数です。大きさを変えると計算効率だけでなく学習結果も変わり得ます。

参考：Google: Linear regression: Hyperparameters

使う場面

1000件のデータを100件ずつ処理する場合、通常は10バッチで1エポックになる。

確認ポイント

重みを一回更新するステップとは異なります。周回を増やしすぎると過学習につながることがあります。

参考：PyTorch: Optimizing Model Parameters

使う場面

学習率をいくつか試し、検証データでよい結果になる設定を選ぶ。

確認ポイント

データから直接学ぶ重みとは区別します。テストデータを見ながら設定を選ぶと、評価が甘くなる原因になります。

参考：PyTorch: Optimizing Model Parameters / scikit-learn: Cross-validation

使う場面

問い合わせと対応カテゴリの組を集め、分類モデルの学習に使う。

確認ポイント

学習データでの成績だけでは、新しい入力への強さは分かりません。評価用データとの重複にも注意します。

参考：Google: Supervised Learning / Google: Dividing the original dataset

使う場面

複数の学習率を試したモデルを検証データで比べ、採用する設定を決める。

確認ポイント

繰り返し結果を見て選ぶため、検証データ自体に合わせすぎることもあります。最終評価用のテストデータは別に保ちます。

参考：Google: Dividing the original dataset

使う場面

完成した分類モデルを、調整に使っていない問い合わせで評価する。

確認ポイント

テスト結果を見て何度も調整すると、独立した最終評価ではなくなります。実際の利用場面を代表する内容かも確かめます。

参考：Google: Dividing the original dataset

使う場面

データを5つに分け、1つずつ検証用に回して得点の平均とばらつきを見る。

確認ポイント

時系列や同じ人からのデータは、無作為に混ぜると情報が漏れることがあります。利用場面に合う分割が必要です。

参考：scikit-learn: Cross-validation

使う場面

学習用と検証用の両方で誤りが多いとき、モデルが単純すぎないか調べる。

確認ポイント

単に学習時間が短い場合だけを指す言葉ではありません。入力情報やモデルの表現力が足りない場合もあります。

参考：Google: Overfitting

使う場面

過去の問い合わせで学習したモデルが、新しく届いた問い合わせも正しく分類できるか確かめる。

確認ポイント

学習データで高得点でも汎化できるとは限りません。利用する時期や対象が変わった場合は改めて評価します。

参考：Google: Overfitting

使う場面

大きすぎる重みにペナルティを加え、検証データでの予測を改善できるか試す。

確認ポイント

強くすれば必ずよいわけではなく、強すぎると必要な傾向まで学べなくなることがあります。

参考：Google: L2 regularization

使う場面

学習用だけ成績がよいニューラルネットワークに導入し、過学習が減るか確かめる。

確認ポイント

通常は学習時に使い、推論時は同じようには無効化しません。重みを恒久的に削るプルーニングとは異なります。

参考：Keras: Dropout layer

使う場面

検証データの損失が数エポック改善しなければ、学習を終了する設定にする。

確認ポイント

一時的な停滞だけで止めないよう、待つ回数や改善幅を決めます。最良時点の重みを復元する設定も別途確認します。

参考：Keras: EarlyStopping

使う場面

一般的な画像で学習したモデルを土台にして、自社商品の画像分類を作る。

確認ポイント

学習済み部分を固定して使う方法も、追加で調整する方法もあります。元の課題と用途が大きく違う場合は効果を確かめます。

参考：Keras: Transfer learning & fine-tuning

使う場面

大きなモデルの回答を使って、軽量なモデルに特定の分類を学ばせる。

確認ポイント

元モデルの能力を全てそのまま移せるとは限りません。手本に誤りがあれば、それを引き継ぐ可能性もあります。

参考：Hinton et al.: Distilling the Knowledge in a Neural Network

使う場面

手元のPCで動かすため、低ビット化されたモデルを候補に入れて品質を比較する。

確認ポイント

量子コンピューターを使う意味ではありません。品質の変化や実際の速度は、方式と実行環境によって異なります。

参考：Hugging Face: Quantization overview

使う場面

小さな重みを減らしたモデルを作り、精度と処理時間がどう変わるか測る。

確認ポイント

重みをゼロにしただけで必ず高速化するわけではありません。保存形式や計算の実装が削減に対応しているかも重要です。

参考：PyTorch: Pruning Tutorial

使う場面

100件の問い合わせのうち90件を正しく分類できた場合、正解率は90%になる。

確認ポイント

珍しいカテゴリを全て見落としても高得点になる場合があります。カテゴリの偏りが大きいときは再現率なども確認します。

参考：Google: Accuracy, recall, precision, and related metrics

使う場面

迷惑メールと判定した10通のうち8通が本当に迷惑メールなら、適合率は80%になる。

確認ポイント

対象をどれだけ取りこぼしたかは分かりません。見逃しの少なさを示す再現率と合わせて見ます。

参考：scikit-learn: precision_score

使う場面

実際の迷惑メール20通のうち15通を検出できた場合、再現率は75%になる。

確認ポイント

全件を対象と判定すれば再現率は高くできますが、誤検出も増えます。適合率と一緒に確かめます。

参考：scikit-learn: recall_score

使う場面

問い合わせ検出モデルの比較で、誤検出と見逃しの両方を意識してF1を確認する。

確認ポイント

単純な算術平均ではありません。複数カテゴリでは集計方法によって値が変わり、実務上の誤りの重さも別に考える必要があります。

参考：scikit-learn: f1_score

使う場面

「返品」の問い合わせを「配送」と取り違える例が多いかを表で調べる。

確認ポイント

行と列のどちらが正解かはツールによって異なります。件数か割合かも確認して読みます。

参考：Google: Thresholds and the confusion matrix

使う場面

迷惑メール判定のしきい値を決める前に、モデル同士のスコアの分け方を比較する。

確認ポイント

特定のしきい値での正解率ではありません。対象が少ない場合は、適合率と再現率の関係も確認します。

参考：Google: ROC and AUC

使う場面

同じ評価文と同じトークン化条件で、低い値になる言語モデルを比較する。

確認ポイント

低いほどその文章を予測しやすいことを示しますが、事実の正確さや会話の役立ち度そのものではありません。トークン化や参照できる文脈が違う値の単純比較は避けます。

参考：Hugging Face: Perplexity of fixed-length models

使う場面

人が比較した回答の好みを学習し、新しい回答の良さを採点する。

確認ポイント

スコアは学習した評価の近似で、正しさや安全性の保証ではありません。評価者や比較データの偏りも影響します。

参考：Ouyang et al.: Training language models to follow instructions with human feedback / Rafailov et al.: Direct Preference Optimization

使う場面

複数の回答を人が比較した結果を使い、好まれやすい応答へモデルを調整する。

確認ポイント

学習時の評価を利用する方式で、毎回の回答を人が確認している意味ではありません。誤りを完全になくす手法でもありません。

参考：Ouyang et al.: Training language models to follow instructions with human feedback

使う場面

同じ質問への良い回答と悪い回答の組を用意し、応答の傾向を追加学習する。

確認ポイント

代表的なRLHF手順のように、別の報酬モデルを明示的に学習して強化学習する工程を必要としません。比較データの質は重要です。

参考：Rafailov et al.: Direct Preference Optimization

使う場面

問い合わせと望ましい返答の組を使って、決まった回答形式を学ばせる。

確認ポイント

ファインチューニングの一種です。回答の好みを比較するDPOとは異なり、基本的には見本の出力を再現するよう学習します。

参考：Hugging Face: SFT Trainer

使う場面

手書き数字の画像から線や曲がりなどの特徴を学び、数字を分類する。

確認ポイント

画像でよく使われますが、画像だけに限る構造ではありません。フィルターの大きさや層の構成も結果に影響します。

参考：PyTorch: Neural Networks

使う場面

センサー値を時間順に読み、直前までの状態を使って次の値を予測する。

確認ポイント

単純なRNNでは、長く離れた情報の関係を学びにくいことがあります。状態があることは会話を永久に記憶する意味ではありません。

参考：Keras: SimpleRNN layer / Google: Training using backpropagation

使う場面

過去の時間変化が重要な、センサー値の予測モデルで使う。

確認ポイント

名前に記憶とありますが、無制限に情報を保存する機能ではありません。系列の長さや学習条件によって性能は変わります。

参考：PyTorch: LSTM

使う場面

同じ写真を別々に切り出した画像を関連する組として、画像の特徴表現を学習する。

確認ポイント

何を関連する組とし、何と区別するかで学べる性質が変わります。自己教師あり学習だけでなく、ラベルを使う方式もあります。

参考：Chen et al.: A Simple Framework for Contrastive Learning of Visual Representations / Khosla et al.: Supervised Contrastive Learning

使う場面

どのツールで画像を作るか選ぶとき。

確認ポイント

得意な作風や文字の扱いはモデルで異なる場合があるため、用途に合わせて選ぶと失敗が減ります。

使う場面

Googleの環境で画像・音声生成を試すとき。

確認ポイント

使える機能や対応モデルは変更される場合があるため、公式画面での確認が役立ちます。

使う場面

画像生成や部分編集を行うとき。

確認ポイント

シリーズ全体の呼び名として使われることもあります。Pro・2・2 Liteを区別し、実際に選択しているモデルを確認します。

参考：Google：画像生成モデル

使う場面

画像がAI生成かどうかを判別する話題で出てくる場面。

確認ポイント

対応する生成物・検出手段には条件があります。透かしが検出されなかったことだけで、人が作ったとは判断できません。

参考：Google DeepMind：SynthID

使う場面

生成画像の出所や編集履歴を確認したいとき。

確認ポイント

来歴の検証と、内容の真偽・権利の確認は別です。来歴情報は失われる場合があり、記録がないことだけで本物とも偽物とも判断できません。

参考：C2PA公式FAQ

使う場面

生成画像を公開・利用する前の確認時。

確認ポイント

仕様やオン／オフの可否はサービスで異なる場合があるため、利用前に確認すると安全です。

使う場面

生成が拒否された・止められたと感じたとき。

確認ポイント

表示された理由と利用条件を確認し、許可される内容かを見直します。誤判定が疑われる場合は、提供元の案内や問い合わせ先を確認します。

使う場面

思った通りの画像にならないとき。

確認ポイント

モデルで差がある場合があり、指示を具体的に分けて書くと精度が上がることがあります。

使う場面

全体は良いが一部だけ直したいとき。

確認ポイント

編集の精度や対応範囲はツールで異なる場合があるため、用途に合うか確認すると安心です。

使う場面

制作物を納品・販売する前。

確認ポイント

利用するサービス・プランの規約、入力素材の権利、生成物に含まれる第三者の権利、納品先の条件を確認します。確認日も残しておくと後で見直せます。

使う場面

画像が段階的に生成される仕組みや、設定項目の意味を理解するとき。

確認ポイント

画像生成AIがすべて同じ方式とは限らず、サービスの画面から内部方式を断定しないようにします。

使う場面

同じ構図に近い結果を再現しながら、指示を少しずつ調整したいとき。

確認ポイント

同じ値でも、モデル・設定・実行環境が変われば完全に同じ結果になるとは限りません。

使う場面

ブログのアイキャッチ、SNS、スライドの画像を作るとき。

確認ポイント

比率と解像度は別です。掲載枠の比率に合わせ、切り抜かれて困る文字や顔を端へ寄せすぎないようにします。

使う場面

背景の一部や写り込んだ物など、限られた範囲を直すとき。

確認ポイント

対象範囲の指定方法はツールで異なります。境界や影、周辺の文字などに不自然な変化がないか確認します。

使う場面

紙の資料、画像内の表、スクリーンショットの内容を取り出すとき。

確認ポイント

文字の認識と、意味や表の構造の理解は別です。数字・記号・読み取り順は、元画像と照らし合わせます。

使う場面

「雨上がりの公園を水彩画で」と入力し、挿絵の案を作る。

確認ポイント

構図や文字の綴りまで、指示どおりになるとは限りません。公開前に細部を確認します。

参考：Hugging Face Diffusers: Text-to-image

使う場面

自分の部屋の写真をもとに、壁の色を変えた案を作る。

確認ポイント

元画像の細部や人物の特徴が変わる場合があります。残したい要素を指定し、結果を見比べます。

参考：Hugging Face Diffusers: Image-to-image

使う場面

縦長写真の左右に背景を足し、横長バナーの素材にする。

確認ポイント

描き足した部分は実際に写っていた景色ではありません。画像の内側を埋めるインペインティングと区別します。

参考：Hugging Face Diffusers: Outpainting

使う場面

画像生成で「文字、ロゴ」を除外項目に入れ、背景素材を作る。

確認ポイント

対応していないモデルもあり、指定した要素を必ず排除できるわけではありません。

参考：Hugging Face Diffusers: Text-to-image

使う場面

人物のポーズを示す骨格図を使い、同じ構えのイラストを作る。

確認ポイント

使う制御画像と対応モデルを合わせます。構造を指定しても、顔や細部まで同一になるとは限りません。

参考：Hugging Face Diffusers: ControlNet

使う場面

対応する画像モデルでCFGの強さを変え、指示の反映と絵の自然さを比べる。

確認ポイント

値を上げれば必ず良くなるわけではなく、画像の乱れや多様性の低下が起きることがあります。

参考：Classifier-Free Diffusion Guidance

使う場面

下絵の構図を残したいとき、強度を低めから試して仕上がりを比べる。

確認ポイント

一般に高いほど元画像から離れやすくなります。尺度や効き方は実装によって違います。

参考：Hugging Face Diffusers: Image-to-image

使う場面

小さい挿絵を拡大し、輪郭や質感を整える。

確認ポイント

AIが補った細部は実物と一致するとは限りません。読めない文字や証拠画像の内容を確定する用途には注意が必要です。

参考：ESRGAN: Enhanced Super-Resolution Generative Adversarial Networks

使う場面

人物の領域だけを選び、背景を差し替える編集用のマスクを作る。

確認ポイント

物体を四角い枠で囲む物体検出とは異なります。髪や透明な物体の境界は確認が必要です。

参考：Hugging Face Tasks: Image Segmentation

使う場面

棚の写真から箱を見つけ、数を数える作業を補助する。

確認ポイント

重なった物体や小さい物体は見落とすことがあります。検出結果だけで正確な在庫数を確定しないようにします。

参考：Hugging Face Tasks: Object Detection

使う場面

写真の手前と奥を分け、背景ぼかしや画像生成の構図制御に使う。

確認ポイント

前後関係だけを出す相対深度と、距離を出す絶対深度があります。すべての結果がメートル単位ではありません。

参考：Hugging Face Tasks: Depth Estimation

使う場面

撮影したダンス動画から骨格の動きを取り出し、アニメーションの参考にする。

確認ポイント

服や物体で隠れた関節は誤推定しやすくなります。人物の身元や気持ちを特定する技術ではありません。

参考：Google MediaPipe: Pose landmark detection guide

使う場面

商品写真に「白い机の上に置かれた青いマグカップ」という説明案を付ける。

確認ポイント

画像内の文字を読むOCRとは目的が違います。見えていない事情や物体を説明に足していないか確認します。

参考：Hugging Face Tasks: Image-to-Text

使う場面

料理写真を示して「皿は何枚ありますか」と質問する。

確認ポイント

小さな文字や細かな数の読み取りは誤ることがあります。画像にない情報まで分かるわけではありません。

参考：Hugging Face Tasks: Visual Question Answering

使う場面

「桜の花びらがゆっくり舞う」と指定し、短い映像の案を作る。

確認ポイント

物の動きや時間のつながりが不自然になることがあります。音声も生成されるかはモデルによって違います。

参考：Hugging Face Diffusers: Video generation

使う場面

自作の風景画をもとに、水面が揺れる映像を作る。

確認ポイント

元画像から動きを推測して作るため、実際の出来事を再現した記録ではありません。

参考：Stability AI: Stable Video Diffusion Image-to-Video Model Card

使う場面

動きのコマ数を増やして、スローモーションをなめらかに見せる。

確認ポイント

新しいコマは推定結果です。速い動きや物体の重なりでは、輪郭の乱れが生じることがあります。

参考：FILM: Frame Interpolation for Large Motion

使う場面

生成動画で、歩く人物の服の色が途中で変わっていないか確認する。

確認ポイント

一枚の画像がきれいでも、動画全体が自然とは限りません。連続再生で変化を確認します。

参考：Hugging Face Diffusers: Video generation

使う場面

許可を得た出演者の教材動画を別言語に吹き替え、口の動きを調整する。

確認ポイント

実在する人が話していない内容を話したように見せられます。本人の許可や合成であることの表示を確認します。

参考：A Lip Sync Expert Is All You Need for Speech to Lip Generation In The Wild

使う場面

会議の録音から文字起こしの下書きを作る。

確認ポイント

固有名詞・数字・同時発話は誤りやすいため、重要箇所は録音と照合します。別言語へ訳す音声翻訳とは異なります。

参考：Hugging Face Tasks: Automatic Speech Recognition

使う場面

案内文を音声にして、画面を見なくても聞けるようにする。

確認ポイント

人名の読み方やアクセントは確認します。自然な声で読まれていても、文章の内容が正しいとは限りません。

参考：Hugging Face Tasks: Text-to-Speech

使う場面

二人のインタビューの文字起こしに、話者ごとのラベルを付ける。

確認ポイント

通常は声を区別する処理で、実名を特定するものではありません。複数人の声が重なると誤りやすくなります。

参考：Google Cloud: Detect different speakers in an audio recording

使う場面

音声チャットで、発話が終わったらAIの応答を開始する判断に使う。

確認ポイント

話の内容を文字にする処理ではありません。短い間を発話の終了と誤認する場合があります。

参考：Google Cloud: Voice activity events and timeouts

使う場面

本人の許可を得て、本人の声に似た教材ナレーションを作る。

確認ポイント

声の持ち主の同意や利用範囲を確認します。本人が実際に発言した音声だと誤解されない表示も重要です。

参考：Transfer Learning from Speaker Verification to Multispeaker Text-To-Speech Synthesis

使う場面

自分で録音したせりふを、利用許可のあるキャラクター声へ変換する。

確認ポイント

文字から読み上げる音声合成とは入力が違います。内容や抑揚まで完全に保たれるとは限りません。

参考：AUTOVC: Zero-Shot Voice Style Transfer with Only Autoencoder Loss

使う場面

日本語の説明を英語の字幕や読み上げに変換する。

確認ポイント

認識と翻訳の両方で誤りが起こり得ます。数字・人名・専門用語は、原音や原稿で確かめます。

参考：Hugging Face Transformers: SeamlessM4T

使う場面

確定済みの字幕原稿に、録音に合う表示時刻を付ける。

確認ポイント

文字起こしを一から作る音声認識とは違います。原稿と実際の発話が食い違うと、時刻がずれる場合があります。

参考：PyTorch Audio: Forced Alignment with Wav2Vec2

使う場面

音声合成で重要な言葉をゆっくり読み、文の区切りに間を入れる。

確認ポイント

同じ文章でも話し方で印象が変わります。調整できる要素や指定の効き方は音声モデルによって違います。

参考：W3C SSML 1.1: prosody Element

使う場面

利用許可のある楽曲から歌声と伴奏を分け、編集用素材を作る。

確認ポイント

取り出した音に別の音が残ったり、音質が変わったりします。話者にラベルを付ける話者分離とは別の処理です。

参考：Music Source Separation in the Waveform Domain

使う場面

録音した解説音声の空調音を弱め、聞き取りやすさを改善する。

確認ポイント

処理を強めると声の一部まで失われることがあります。元の録音を残し、聞き比べて確認します。

参考：Real Time Speech Enhancement in the Waveform Domain

使う場面

連続で使ってエラー表示が出たとき。

確認ポイント

エラー本文で原因を確認します。待機が必要な制限と、残高・割り当て上限の問題では対処が異なります。案内された再試行間隔を守ります。

使う場面

機能が急に使えなくなったとき。

確認ポイント

多くは時間を置くと回復する場合があり、公式の稼働状況も確認の手がかりになります。

使う場面

反応が遅い、生成が失敗するとき。

確認ポイント

時間帯を変えると改善する場合があり、自分側の不具合と切り分ける手がかりになります。

使う場面

古い表示が残る・更新が反映されないとき。

確認ポイント

ブラウザのキャッシュと、AIのプロンプトキャッシュは別です。削除する場合は、対象と失われるデータを確認します。

使う場面

急にログアウトされた・操作が途切れたとき。

確認ポイント

期限切れやCookieの設定などで状態が失われることがあります。未保存の内容を控えたうえで、再ログインなどを試します。

使う場面

画面表示が崩れる・ボタンが効かないとき。

確認ポイント

自動翻訳が原因で不具合が出る場合があり、オフにすると直ることがあります。

使う場面

ログインできない・連携が切れたとき。

確認ポイント

連携元の権限やログイン状態に依存する場合があり、再連携で解消することがあります。

使う場面

外部連携やコードからの呼び出しが失敗したとき。

確認ポイント

エラー番号で原因が分かれる場合が多く、キーや上限・形式の確認が切り分けに役立ちます。

使う場面

ダウンロードや保存ボタンが反応しないとき。

確認ポイント

通信・容量・権限・ブラウザ設定が原因の場合があり、環境を変えて試すと切り分けやすくなります。

使う場面

AI APIの応答を長く待ち続けないよう、待ち時間の上限を設定するときに使います。

確認ポイント

待機を打ち切っても、相手側の処理が止まったとは限りません。再実行前に処理の状態や重複の影響を確認します。

参考：AWS: Set client timeouts

使う場面

一時的な通信障害でAI APIの呼び出しに失敗した際、間隔を空けて再度試すときに使います。

確認ポイント

入力の誤りなど、繰り返しても直らない失敗もあります。回数の上限を決め、送信や更新の二重実行を防ぎます。

参考：AWS: Control and limit retry calls

使う場面

APIが混雑しているときに、すぐ連打せず間隔を広げながら再試行するときに使います。

確認ポイント

待ち時間と再試行回数には上限を設けます。少しランダムなずれを加えると、多数の利用者の再試行が同時に集中するのを抑えられます。

参考：AWS: Retry with backoff pattern

使う場面

AI APIが失敗した時刻、要求の識別子、エラー内容を調べ、原因を絞り込むときに使います。

確認ポイント

会話履歴や英語学習の間違いログとは用途が異なります。秘密鍵や個人情報を不用意に記録しないようにします。

参考：OpenTelemetry: Logs

使う場面

質問、要約、下書き、画像理解、制作支援などを一つの入口から行いたいとき。

確認ポイント

利用できる機能はプランや画面で異なる場合があるため、目的と現在の公式表示を合わせて確認します。

使う場面

Grokの全体像や使い方を知りたいとき。

確認ポイント

機能やプランは更新される場合があるため、最新の公式情報と合わせて確認すると安心です。

使う場面

Grokで画像や動画を作りたいとき。

確認ポイント

生成上限や仕様は変わる場合があるため、利用前に最新の条件を確認すると安心です。

使う場面

無料枠より多く使いたいとき。

確認ポイント

料金や含まれる機能は変更される場合があるため、公式の料金表で確認すると確実です。

使う場面

Geminiや画像生成を手軽に試すとき。

確認ポイント

画面での試用とAPI利用の条件は分けて確認します。モデル・機能によって無料枠や課金条件が異なります。

使う場面

Googleのモデルを選ぶ・比較するとき。

確認ポイント

アプリ名・モデル名・契約プランを区別します。同じGeminiでも、利用する入口やモデルで機能・料金が変わります。

使う場面

より高品質な画像生成や編集を行うとき。

確認ポイント

Proという名称だけで用途への適性は決まりません。利用場所の料金・上限と、必要な文字表現や編集の結果を確かめます。

参考：Google：画像生成モデル

使う場面

文章作成や読み込み作業を任せたいとき。

確認ポイント

機能やモデルは更新される場合があるため、用途に合うか最新情報で確認すると安心です。

使う場面

開発作業をAIに手伝ってもらうとき。

確認ポイント

実行できる操作の範囲を理解し、内容を確認しながら使うと安全です。

使う場面

コードの生成や修正を任せたいとき。

確認ポイント

実行できる操作や権限は利用環境で異なります。変更内容とテスト結果を確認し、必要なレビューを行います。

参考：OpenAI：ChatGPT Work

使う場面

AIと一緒にコードを書き進めたいとき。

確認ポイント

提案の採否は自分で判断する前提で使うと、品質を保ちやすくなります。

使う場面

自分の資料をもとに整理・理解したいとき。

確認ポイント

回答は読み込ませた資料に依存するため、元資料の正確さが結果を左右します。

使う場面

資料を読み比べながら、確認工程を挟んで文書などを仕上げたいとき。

確認ポイント

提供状況や使える機能は、プラン・組織の設定・利用環境で確認します。共有や外部操作を含む作業は、対象と内容を確かめます。

参考：OpenAI：ChatGPT Work

使う場面

対応する入口、APIのモデル名、料金や上限を確認するとき。

確認ポイント

現在選べるモデルと正式なAPIモデルIDを公式一覧で確認します。月額プランとAPIの利用料金は分けて考えます。

参考：Cursor：Grok 4.5の発表