AIを使ってアプリや業務の自動化を進めると、「作りたいことはあるのに、どう頼めばよいか分からない」という場面に出会います。動くものができても、何を確かめれば十分なのか迷うこともあります。

そんなときに役立つのが、ソフトウェア開発の用語と手法です。問題へ名前を付けられると、依頼する内容と確認する範囲を具体的にできます。

Kanau Techでは、AI支援開発で使う知識を 15分野・200項目の学習カード に整理しました。要件、画面、設計、データ、テスト、公開、運用に加え、AIへ渡す情報とAIの評価まで扱います。

各カードには「意味・使う場面・具体例・AIへの依頼文・結果の確認・注意点・出典」を付けました。この記事では、全体像と実際の使い方を紹介します。

資料確認日：2026年10月12日。200は関連語をまとめたものを含むカード項目数です。全分野の全用語を網羅した辞典ではありません。出典・関連資料は75件。57項目は関連原則に基づく整理で、用語の直接定義との照合が残っています。該当カードに表示しています。効率改善率は未測定です。

専門用語を、依頼と確認へつなげる

例えば、再送すると同じ申請が二件登録される問題を考えてみます。

「二重登録を直して」だけでは、連続クリック、通信切断後の再送、同時実行のどこまで直すかが曖昧です。ここで Idempotency（冪等性） という考え方を知っていると、繰り返した操作の効果をどう扱うか具体化できます。

申請登録の再送で、同じ申請を重複保存しないようにしてください。
同一操作を識別するIdempotency keyの範囲と保存期間を定義してください。
同じキーで異なる内容が届いた場合の扱いも決めてください。
通信切断後の再送と同時再送で確認し、保存件数を示してください。

AWSの解説でも、副作用のあるAPIの再試行には、同じ意図の操作を識別する設計を扱っています。タイムアウトしても、相手側で処理が完了している可能性があるためです。AWS Builders' Library

使う順番は次のとおりです。

困りごとを一つ選ぶ。
対応する用語と使う場面を読む。
目的・入力・制約・期待結果をAIへ渡す。
小さな変更で試す。
実行結果で確かめ、次の依頼を改善する。

AI開発で学びたい15分野の全体図

図は開くと拡大できます。工程ごとの用語と、判断したい問いを対応させています。

分野	判断したいこと	代表的な用語
要件・課題	何を作れば受け入れられるか	Acceptance criteria、Specification by Example、DoD
画面・UX	利用者が迷わず操作できるか	Accessibility、Form validation、State management
設計	責任と依存が明確か	Separation of Concerns、Interface、ADR
作業計画	小さく作って確かめられるか	Vertical slice、Small batch、WIP limit
コード品質	変更しやすく保てるか	YAGNI、DRY、Refactoring
データ・DB	途中失敗や同時更新を扱えるか	Transaction、Constraint、Migration
API・連携	再送や相手の失敗に備えているか	Idempotency key、Timeout、Retry
テスト品質	実装の誤りを見抜けるか	Test oracle、Tautological test、Mutation testing
Git・レビュー	変更内容と経緯を追えるか	Diff、Commit、Code review
セキュリティ	必要な操作だけ許可できるか	Authorization、Least privilege、Prompt injection
ビルド・公開	確認した変更を届けられるか	CI/CD、Feature flag、Rollback
運用・改善	異常を検知し、復旧できるか	Observability、SLO、Root Cause Analysis
性能・コスト	計測して改善できているか	Profiling、Caching、Cost budget
AIの指示・情報	必要な情報と根拠を渡せるか	Context engineering、Grounding、RAG
AI実行・評価	行動と成果を確かめられるか	Harness、Tool contract、Evals

最初に使いたい20項目

最初から200項目を暗記する必要はありません。まずは次の20項目を入口にし、今の作業に関係するものを使ってみてください。カード集の「最初の20項目」ボタンでも絞り込めます。

作る内容と変更範囲を決める

Acceptance criteria：受入条件。 その機能を受け入れる具体的な条件を決めます。
Specification by Example：具体例による仕様化。 入力・状況・期待結果の例で認識を合わせます。
Definition of Done（DoD）：共通の完了基準。 確認結果や必要な手順を含め、完了と呼べる状態を揃えます。
Vertical slice：機能を縦に切る。 一つの利用場面を、画面から保存まで通して作ります。
Small batch：小さな変更単位。 確認と統合ができる大きさで変更します。
YAGNI：必要になるまで作り込まない。 未確認の将来要求による機能追加を抑えます。

Small batchは、AIが大量のコードを生成する場面でも使いたい考え方です。DORAは、変更単位を小さくして早くフィードバックを得る実践を説明しています。DORA：Working in small batches

変更しやすく、誤りを検出できるようにする

Separation of Concerns（SoC）：関心の分離。 異なる役割や変更理由を分けます。
ADR：設計判断の記録。 背景・選択・理由・結果を短く残します。
Refactoring：構造の改善。 外部の振る舞いを保ちながら内部を整理します。
Transaction：更新をまとめる単位。 一連の処理が途中で失敗した場合の整合性を考えます。
Idempotency key：再送を識別するキー。 同じ意図の操作による効果の重複を防ぎます。
Test oracle：正しさを判定する根拠。 承認済みの仕様例など、期待結果の根拠を持ちます。
Tautological test：同語反復的なテスト。 実装と期待値が同じ誤りに依存する確認を見直します。
Regression test：回帰テスト。 変更によって既存の期待動作が壊れていないか確かめます。

公開後とAIの挙動を管理する

Authorization：認可。 誰が、どのデータへ、何をできるか判定します。
CI：継続的インテグレーション。 小さな変更を統合し、自動ビルドや確認を行います。
Rollback / Roll forward：復旧の選択肢。 以前へ戻すか、修正版を適用するか決めます。
Observability：観測可能性。 ログや指標などから内部の動きを理解できる状態にします。
Context engineering：文脈の設計。 AIへ渡す目的・資料・履歴・ツール情報を選び、管理します。
Evals：AIの評価。 代表的な課題と基準で、変更前後の成果を比べます。

優先順位は学習上の目安です。本番で必要な権限制御や復旧方法を、未学習だから後回しにできるという意味ではありません。

Tautological testを具体例で理解する

Tautological testは、テストの対象と期待値が同じ根拠に依存し、誤りを見逃す問題を説明する際の呼称です。ここではSpecStoryの解説に沿って使い、統一された規格用語とは扱いません。SpecStory：Tautological tests

例えば「100円の10％引きは90円」という仕様があるとします。実装が間違って80円を返していても、期待値を同じ実装から作ればテストは通ります。

// 期待値にも対象の実装を使うため、割引計算の誤りを検出できません。
expect(discountedPrice(100, 0.1)).toBe(discountedPrice(100, 0.1));

// 承認した仕様例を期待値として使います。
expect(discountedPrice(100, 0.1)).toBe(90);

AIへは次のように依頼できます。

割引計算のテストについて、期待値の根拠を一覧にしてください。
実装の計算を期待値にも使うTautological testがないか確認してください。
承認済みの仕様例から期待値を定め、境界値と不正入力も確認してください。
実装へ小さな誤りを入れたとき、テストが失敗するか確かめてください。

重要な分岐の検出力を調べる方法には、Mutation testingもあります。意図的な小変更を入れ、テストが検出するか評価する手法です。全コードへ一律に導入せず、重要度と実行費用で範囲を選びます。Stryker：Mutation testing

作業に合わせて、用語を組み合わせる

一つの用語で解決できる範囲には限りがあります。作業の目的に合わせ、関連する概念を組み合わせます。

困りごと	組み合わせたい用語	確認する結果
AIが勝手に機能を増やす	Acceptance criteria、YAGNI、Small batch	合意した範囲に収まっている
テストは通るが誤動作する	Test oracle、Tautological test、Regression test	誤った実装なら失敗する
再送で二重登録される	Idempotency key、Unique constraint、Transaction	同時再送でも効果が重複しない
他人のデータが見えてしまう	Authorization、Least privilege、Deny by default	権限外の直接アクセスを拒否する
公開後に戻せない	Migration、Expand-contract、Rollback、Backup	コードとデータの復旧方法がある
AIの改善が感覚頼みになる	Evals、Holdout、Grader、Cost budget	同じ課題で品質・時間・費用を比べられる

作業別の依頼テンプレートは、新機能、バグ修正、テスト品質、二重登録、API連携、権限、公開、性能、文脈管理、AI評価、長時間作業、構造改善の12種類を用意しました。

12種類の依頼テンプレートを読む

テンプレートへ、自分の目的・現状・入力例・変更範囲・完了条件を加えて使ってください。

用語を使うときに避けたい誤解

DRYを、似たコードの無条件な共通化に使わない

DRYは、同じ知識や意図の基準が複数へ散る問題を扱います。見た目が似ていても、変更理由が異なる処理をまとめると、修正の影響が広がる場合があります。依頼では「何が同じ知識なのか」を説明することが大切です。Hunt・Thomas：DRY

Retryには、上限と副作用の確認を付ける

再試行は一時障害への対策です。認証失敗などを繰り返しても改善しません。待ち時間、回数上限、Backoff、Jitter、最終失敗時の扱いを決めます。副作用のある操作では、再送による重複も確認します。AWS：Timeouts, retries, and backoff with jitter

Rollbackだけでデータが戻るとは考えない

コードを以前へ戻しても、削除・更新したデータは自動では復元されません。Migrationの互換性、Backup、Restoreを別に確認します。新旧の実装が共存できるよう、変更を段階化するExpand-contractも選択肢になります。Parallel Change

AIへの注意書きと、実行権限の制御を組み合わせる

外部資料には、AIの行動を変えようとする命令が混じる可能性があります。指示と資料を区別する設計に加え、使えるツール、ファイル、通信、操作の権限を制限します。OWASP：Prompt Injection Prevention

AIに任せるために、何を身につけるか

開発では、作る目的、許容できる失敗、期待結果、異常時の対応を判断する必要があります。AIへ任せる範囲が広がっても、成果物を受け入れるための根拠は必要です。

学び始めるときは、現在の作業で使える知識を一つ選びます。分からない語をAIへ聞き、例を作り、公式資料や現物と照合し、自分の言葉で説明してみてください。

コードの確認範囲も、変更内容とリスクに合わせて決めます。認証・権限・金銭・削除・外部送信に関わる処理では、実装と実行結果を確かめる体制が必要です。「AIが作った」「別のAIも正しいと言った」という説明だけでは、確認を終えたことにはなりません。

AIの成果を改善する際は、代表例と失敗例によるEvalsを用意し、成功条件を先に決める方法が役立ちます。モデルによる採点を使う場合も、判定の妥当性を確かめます。Anthropic：Demystifying evals for AI agents

カード集の使い方とダウンロード

カード集は、ログインなしで利用できます。

200項目を検索する：日本語の困りごと、英語の用語、分野、種類、学習優先度で探せます。
作業別の依頼テンプレート：12種類の作業へ用語を組み合わせた例です。
図・カード・テンプレートをZIPで保存：展開して index.html を開くと、オフラインでも検索できます。
CSVを保存する：自分の学習記録へ取り込めます。
出典75件と確認範囲：直接定義の追加照合が残る57項目も確認できます。

最初の一歩は、今の困りごとを一つ検索することです。カードの依頼文へ条件を加え、確認方法で結果を確かめます。使った用語、確認結果、手戻りを記録し、次の作業へつなげてください。

時間短縮の効果を測るときは、似た規模の作業で、着手から受入までの時間、修正の往復、不具合、費用を比べます。モデルや環境、難しさが異なる場合は、その条件も残します。

Kanau Techは、AIで作る工程と、人が理解して運用できる状態を一緒に整えることを重視しています。用語を、具体的な依頼と確認に使うための資料として活用してください。

資料の範囲と今後の更新

対象はWebアプリ、API、業務自動化、AI支援開発です。言語構文の全項目、専門アルゴリズム、OS・ネットワークの深い理論、全設計パターン、業界別規格、AI学習手法の全体は収録していません。

定義の短い説明、具体例、依頼文、優先度は学習用に編集しています。手法は一律に導入せず、利用する技術と業務条件に照らして選んでください。製品の設定、バージョン、料金、脆弱性情報は、実装する時点で再確認が必要です。

今後は、直接定義の追加照合と、実際に使った依頼・確認結果に基づく更新を進める対象とします。改善率や導入実績が得られていない段階で、効果の数字は掲載しません。

AI開発で学ぶべき用語・手法｜15分野200項目の実務ガイド