AIを使った開発の打ち合わせでは、聞き慣れない言葉が次々に出てきます。分からないまま頷いていると、あとで見積書や提案書を読むときに困ります。この用語集は、発注する側が知っておけば十分な22語に絞りました。各語を「ひとことで」「もう少し詳しく」「発注側のポイント」の3段で説明します。上から読む必要はありません。分からない言葉が出てきたときに、引いてください。
AIに仕事をさせる言葉：AIエージェント ／ プロンプトエンジニアリング ／ コンテキストエンジニアリング ／ ハーネスエンジニアリング ／ ループエンジニアリング ／ ヒューマン・イン／オン・ザ・ループ ／ オーケストレーターとサブエージェント ／ ガードレール
開発の進め方の言葉：AI駆動開発 ／ バイブコーディング ／ FDE ／ 評価データセット ／ PoC
負債とリスクの言葉：技術的負債 ／ 理解負債・認知負債 ／ ベンダーロックイン ／ AI利用の開示
AIそのものの言葉
生成AI・LLMGenerative AI / Large Language Model
ひとことで文章や画像、プログラムを「作れる」AIのこと。LLMはそのうち、文章を扱う大規模なもの。
もう少し詳しくChatGPTやClaudeの中身がLLMです。大量の文章を学習して、「次に来そうな言葉」を予測し続けることで文章を組み立てます。検索エンジンのように答えを探してくるのではなく、その場で作っています。だから流暢で、だからときどき間違えます。
発注側のポイント「AIを使います」と言われたら、どのLLMをどう使うのかまで聞いてよい話です。モデルの名前そのものより、次の項目以降の「どう使うか」のほうが品質を左右します。
トークンとコンテキストウィンドウToken / Context Window
ひとことでトークンはAIが文章を数える単位。コンテキストウィンドウは、AIが一度に覚えていられる量。
もう少し詳しく日本語なら1文字がおおむね1〜2トークンです。AIには「今回の会話で見える範囲」に上限があり、それを超えた分は忘れます。長い仕様書を丸ごと渡しても、全部が同じ重みで読まれるとは限りません。利用料金もトークン数で決まります。
発注側のポイント「資料は全部AIに読ませてあります」という説明は、そのままでは信用しないでください。何を、どの順で、どれだけ読ませたかが品質を決めます。
ハルシネーションHallucination
ひとことでAIが、もっともらしい嘘を自信たっぷりに言うこと。
もう少し詳しく存在しない法律の条文、実在しない論文、動かないプログラムの関数。LLMは「それらしい続き」を作る仕組みなので、知らないことも埋めてしまいます。悪意はなく、本人（AI）も気づいていません。減らすことはできますが、ゼロにはなりません。
発注側のポイント「AIの出力をどう検証していますか」は、最初に聞くべき質問です。答えが「経験のあるエンジニアが目で見ます」だけなら、次の評価データセットの項目を読んでから、もう一度聞いてください。
RAGRetrieval-Augmented Generation
ひとことでAIに答えさせる前に、関係する資料を探して渡してから答えさせる仕組み。
もう少し詳しく社内規程や製品マニュアルをAIに丸暗記させるのではなく、質問が来るたびに関係する部分を検索して、それを読ませたうえで答えさせます。「社内文書に基づいて答えるAI」の多くはこの方式です。資料が更新されれば答えも変わるので、学習し直す必要がありません。
発注側のポイントRAGの品質は、AIの賢さより「探してくる資料の整理具合」で決まります。社内文書が散らかっていれば、答えも散らかります。導入前に、資料の棚卸しが必要かどうかを確認してください。
ファインチューニングFine-tuning
ひとことでAIそのものを、自社のデータで追加学習させること。
もう少し詳しく話し方や出力の形式を自社流に寄せたいときに使います。ただし費用も手間もかかり、資料が変わるたびにやり直しになります。多くの業務用途では、上のRAGと丁寧な指示で足りることが多く、ファインチューニングが本当に必要な場面は限られます。
発注側のポイント提案書に「ファインチューニング」とあったら、「RAGや指示の工夫では足りない理由」を聞いてください。答えられない場合は、費用の割に効果が薄い可能性があります。
AIに仕事をさせる言葉
AIエージェントAI Agent
ひとことで質問に答えるだけでなく、自分で道具を使って仕事を進めるAI。
もう少し詳しく「この機能を作って」と頼むと、ファイルを読み、プログラムを書き、テストを実行し、失敗したら直し、できたら報告する。この一連を自分で回すものをエージェントと呼びます。チャットAIとの違いは、途中で人が指示しなくても次の手を自分で決めることです。
発注側のポイント自分で動く分、止め方の設計が要ります。「何をしてよくて、何をしてはいけないか」を決めているかどうかは、AIエージェントに業務を任せる前提条件にまとめています。
プロンプトエンジニアリングPrompt Engineering
ひとことでAIへの頼み方を工夫すること。
もう少し詳しく「あなたは経験豊富な税理士です」と役割を与える、例を見せる、出力の形式を指定する。こうした頼み方の工夫で、同じAIでも結果が大きく変わります。AI活用の最初の段階で、いまも大事ですが、これだけで品質を保つのは限界があります。
発注側のポイント「プロンプトを工夫しています」は、いまでは当たり前の話です。差がつくのは、次の3つ（コンテキスト・ハーネス・ループ）です。
コンテキストエンジニアリングContext Engineering
ひとことでAIが判断するのに必要な情報を、毎回きちんと揃えて渡すこと。
もう少し詳しく仕様書、社内の書き方のルール、関係するファイル、これまでの経緯。人間の新人でも、これが無ければ良い仕事はできません。AIも同じで、頼み方より「何を見せたか」のほうが効きます。何を渡し、何を渡さないかを設計するのがこの仕事です。
発注側のポイント御社の業務ルールや過去の経緯を、開発会社がどうAIに渡しているかを聞いてください。口頭の説明だけで済ませていると、AIには届いていません。
ハーネスエンジニアリングHarness Engineering
ひとことでAIが安全に作業できるように、周りに「足場」を組むこと。
もう少し詳しく自動テスト、書き方の検査、触ってよい範囲の制限、作業の記録、迷ったときに人へ聞きに来る経路。「テストを通してね」と頼むのがプロンプト、「テストが通らないと次へ進めない」と仕組みで縛るのがハーネスです。お願いではなく、環境側の強制力です。
発注側のポイントAIを使う会社を見極めるなら、「どんなハーネスがありますか」が最も鋭い質問です。「気をつけています」が答えなら、それはハーネスではなく心がけです。ループエンジニアリングを、開発ではなく「会社」に適用するで詳しく書いています。
ループエンジニアリングLoop Engineering
ひとことでAIに指示を出すこと自体を自動化して、人が居なくても仕事が回り続ける仕組みを作ること。
もう少し詳しく決まった条件で起動し、作業し、検証し、報告する。この一巡を人の手なしで繰り返す設計です。ただし、上のハーネスが無いまま回すと暴走します。ループはハーネスの上に載るもので、順番は逆にできません。
発注側のポイント「自動で回っています」と聞いたら、「止まるべきときに止まる仕組みはありますか」と返してください。速さより、止まり方のほうが大事です。
ヒューマン・イン／オン・ザ・ループHuman-in-the-loop / Human-on-the-loop
ひとことで「イン」は人が作業の途中に入って一つひとつ確認すること。「オン」は外から見ていて、おかしいときだけ止めること。
もう少し詳しく一文字違いですが、働き方はまったく違います。イン・ザ・ループは検品係、オン・ザ・ループは監督です。AIの精度が上がるほど、人の役割は前者から後者へ移ります。ただし、どこで人が見るかは、自動で決まるものではなく、設計で決めることです。
発注側のポイント「人間が最終確認します」と聞いたら、「どの作業を、どの段階で」まで確認してください。全部を見ると宣言している場合、実際にはどれも見ていないことがあります。
オーケストレーターとサブエージェントOrchestrator / Sub-agent
ひとことでオーケストレーターは仕事を割り振る指揮役のAI。サブエージェントは、割り振られた一部を担当するAI。
もう少し詳しく大きな仕事を1つのAIに全部やらせるより、設計担当・実装担当・検査担当と分けて、指揮役がまとめるほうが安定します。人間の組織と同じで、担当を分けると、それぞれが見るべき情報が絞られ、間違いも見つけやすくなります。
発注側のポイント「AIチーム」という言葉が出てきたら、それはこの構成のことです。誰（どのAI）が何を担当し、最終的に誰（人間）が責任を持つのか、体制図で見せてもらってください。
ガードレールGuardrails
ひとことでAIがやってはいけないことを、あらかじめ決めて防ぐ仕組み。
もう少し詳しく個人情報を出力しない、本番のデータを消せない、社外に送信できない、決まった金額以上の支払いを起こせない。ハーネスの一部で、とくに「危ない方向」に対する柵です。プロンプトで「やらないでね」と頼むのではなく、そもそもできない環境にしておくのが本来の形です。
発注側のポイント御社のデータを扱わせるなら、「AIが消せないもの・送れないものは何ですか」を聞いてください。答えが具体的であるほど、安心して任せられます。
開発の進め方の言葉
AI駆動開発AI-Driven Development
ひとことでAIエージェントが設計・実装・テストの中心を担い、人が方向づけと最終判断をする開発のやり方。
もう少し詳しく人がコードを書いてAIに補助させるのではなく、AIが書き、人が「何を作るか」「これでよいか」を決めます。数日で動くものが出てくるのが特徴で、仕様書を待ってから作り始める従来の順番が変わります。全体像はAI駆動開発とはにまとめています。
発注側のポイント速さは手段で、目的ではありません。「早く出てきたものを、あとから直せるか」まで含めて見てください。
バイブコーディングVibe Coding
ひとことでプログラムの中身を読まずに、AIに話しかけるだけで作ってしまうやり方。
もう少し詳しく「勤怠の申請アプリを作って」で動くものが出てくる、その手軽さを指す言葉です。試作や自分用の道具には向いています。一方で、中身を誰も読んでいないので、壊れたときに直せない、認証が抜けている、といった問題が起きやすくなります。
発注側のポイント社内で誰かが作った「便利なアプリ」が、気づかないうちに業務システムになっていることがあります。線の引き方はバイブコーディングで作った業務アプリが、半年後に誰も直せなくなるで書いています。
FDEForward Deployed Engineering
ひとことで開発チームが、発注側の現場に入り込んで一緒に作る進め方。
もう少し詳しく仕様書を受け取って持ち帰り、納品して終わり、ではなく、課題の整理から運用・改善まで同じチームが現場で続けます。要件が固まっていない段階から始められるのが利点です。もともとは優秀なエンジニアを一社に張り付ける贅沢な体制で、AIによって現実的な費用でできるようになりました。
発注側のポイント「現場に来る」の中身は会社によって違います。週に何度、誰が、何を見るのか。FDEとはで、SESや請負との違いを整理しています。
評価データセットEvaluation Dataset / Evals
ひとことでAIの出力が合っているかを機械的に採点するための、「問題と正解」の一覧。
もう少し詳しく「この入力にはこう答えるのが正しい」という組を数十〜数百件用意しておき、AIやプロンプトを変えるたびに自動で採点します。人が目で見て「良さそう」と判断するのではなく、点数で比べられるようにするのが目的です。これがあると、モデルを乗り換えても品質が落ちていないかをすぐ確かめられます。
発注側のポイントAIを使ったシステムを納品してもらうなら、この評価データセットも一緒に受け取ってください。プログラム本体より、こちらのほうが長く価値を持ちます。
PoCProof of Concept
ひとことで本格的に作る前に、「本当にできるのか」を小さく試すこと。
もう少し詳しく概念実証と訳されます。AIの案件では、期待どおりの精度が出るかを確かめるために行われることが多いです。問題は、PoCが終わっても本番に進まない「PoC止まり」で、原因の多くは技術ではなく、本番で使うデータと運用する人が決まっていないことにあります。
発注側のポイントPoCを始める前に、「うまくいったら誰が本番で使い、誰が運用するか」を決めておいてください。それが決まっていないPoCは、成功しても止まります。
負債とリスクの言葉
技術的負債Technical Debt
ひとことで急いで作ったツケが、あとから修正や拡張の手間として返ってくること。
もう少し詳しく借金にたとえた言葉です。その場しのぎの作りは、動いている間は問題になりませんが、直そうとした瞬間に利子付きで請求が来ます。AI以前からある言葉で、AIで速く作れるようになった分、借りやすくもなりました。
発注側のポイント負債そのものは悪ではありません。「どこに負債があるか分かっていて、返す計画があるか」が問題です。開発会社に「いま分かっている負債は何ですか」と聞いてみてください。
理解負債・認知負債Comprehension Debt / Cognitive Debt
ひとことで理解負債は、AIが書いたものを誰も理解していないまま抱えている状態。認知負債は、頼りきることで人の考える力そのものが衰えること。
もう少し詳しく技術的負債は「コードの質」の話ですが、理解負債はコードが完璧でも発生します。読んでいない人が運用している限り、障害や引き継ぎのときに請求が来ます。2026年に入って広まった言葉で、AIで作った量が人の読む速度を追い越したことが背景にあります。
発注側のポイント「担当者が抜けたら、何が失われますか」を聞いてください。答えが「頭の中にある」なら、それは理解負債です。私たちの対処は全員AIの会社は「理解負債」をどう払っているかに書いています。
ベンダーロックインVendor Lock-in
ひとことで特定の会社や製品から、乗り換えたくても乗り換えられなくなること。
もう少し詳しくAIの場合、特定のモデルの癖に合わせてプロンプトや処理を作り込むと、別のモデルに変えたときに動かなくなります。AIの利用料金は下がり続けているので、乗り換えられない状態は、値下がりの恩恵を受けられない状態でもあります。モデルを差し替えても壊れない作りにしておくのが対策です。
発注側のポイント「モデルを別のものに変えたら、どこを直す必要がありますか」と聞いてください。生成AIはやがて安くなる時代の投資判断で、この観点を掘り下げています。
AI利用の開示AI Disclosure / Provenance
ひとことで成果物のどこに、どの程度AIを使ったかを明らかにすること。
もう少し詳しく文章やイラストの世界で先に広まった考え方ですが、プログラムにも及び始めています。AIが生成したコードには著作権が発生しないという見解があり、納品物の権利や責任の整理に関わってくるためです。「使った・使っていない」の二択ではなく、どの工程にどの程度かを段階で表す方法が模索されています。
発注側のポイント契約書の著作権の条項が、AI生成物を前提にしていないことがあります。開発会社に「AI利用の範囲を納品時に開示できますか」と聞いてください。私たちは作品づくり向けの開示規格として来歴区分表を公開しており、考え方の参考になります。
おわりに——言葉より、質問を持ち帰ってください
22語を並べましたが、覚える必要はありません。この用語集で持ち帰っていただきたいのは、各項目の「発注側のポイント」に書いた質問のほうです。「どう検証していますか」「どんなハーネスがありますか」「担当者が抜けたら何が失われますか」。この3つを聞くだけで、AIを使う開発会社の実力はかなり分かります。
言葉は今後も増え、変わっていきます。この記事も、新しい言葉が定着したら追記していきます。
質問は、直接ぶつけてください。
JumpStackは、お客さまの現場にAIチームを配置するFDEを軸に、課題の定義から実装・運用までをご一緒しています。この用語集の「発注側のポイント」に書いた質問は、そのまま私たちに聞いていただいて構いません。
開発の進め方を相談する