AI時代の『プリンシプルオブプログラミング』用語集

A

AOP（アスペクト指向プログラミング） A

Aspect-Oriented Programming

ログや認証など複数の場所にまたがる共通処理を「アスペクト」としてまとめて注入する設計・実装のスタイル。

💡AIワンポイント

AOPを使う場面では、AIに「横断関心だけを切り出す」制約を渡すのが重要です。業務ロジックまでアスペクトへ寄せる提案は、保守性低下のサインです。

アサーション A

Assertion

アサートによってチェックされる「こうであるべき」という条件そのものを指す言葉。テストコードでもよく使われる。

💡AIワンポイント

アサーション文は「何を信じてよいか」をAIと共有する手段です。テストレビューでは期待条件が仕様語彙と一致しているかを確認するとズレを減らせます。

アサート A

Assert

常に成り立つべき条件をコード中で確認するための命令。条件が崩れたら即座にエラーにして、バグに早く気づけるようにする。

💡AIワンポイント

アサートはAI生成コードの暴走を止める保険になります。壊れてはいけない前提を明示しておくと、誤った最適化が入っても早い段階で検知できます。

アノテーション A

Annotation

コードに付ける小さな注釈。フレームワークなどが読み取り、設定やバリデーション、追加処理などを自動で行うために使われる。

💡AIワンポイント

アノテーションは便利ですが、AIが付け過ぎると挙動が読めなくなります。付与条件をルール化し、暗黙設定が増えていないかをレビューで抑えるのが有効です。

アーキテクチャ A

Architecture

システム全体の大まかな構造や部品の分け方、どのように連携させるかを決める設計の考え方。

💡AIワンポイント

アーキテクチャをAIに相談するときは、守る層境界と依存方向を先に固定します。構造制約が明確だと、部分実装を積み上げても全体が崩れにくくなります。

詳しく見る

抽象度 A

Abstraction

具体的な細部を隠し、共通する考え方や性質に注目して表現すること。高すぎても低すぎても分かりにくくなる。

💡AIワンポイント

抽象度が揃っていないコードは、AIが誤った層で実装しがちです。依頼前に「この関数の抽象レベル」を一文で定義すると、生成結果の一貫性が上がります。

B

ビルド B

Build

ソースコードをコンパイルしたりまとめたりして、実行可能なアプリケーションや配布物の形に変換する処理。

💡AIワンポイント

ビルド用スクリプトはAIに1回で完成を期待せず、環境差分を明記して段階生成させるのが堅実です。成果物名と出力先を固定すると自動化パイプラインに載せやすくなります。

C

CI（継続的インテグレーション） C

Continuous Integration

開発者の変更をこまめに統合し、自動ビルドと自動テストを回して問題に早めに気づけるようにする開発のやり方。

💡AIワンポイント

CI定義をAIに書かせるときは、失敗時に止めるジョブ順序を明示します。高速化よりも再現性を優先し、同じ入力で同じ結果になるかを最初に検証します。

CLI C

Command Line Interface

Command Line Interface の略で、キーボードからコマンドを打って操作するインターフェース。慣れると繰り返し作業を素早く行える。

💡AIワンポイント

CLIはAIエージェントの操作面になるため、引数契約と終了コード設計が重要です。標準出力とエラー出力の責務を分けると自動実行の安定性が上がります。

凝集度（Cohesion） C

Cohesion

1つのモジュールやクラスの中には、同じ目的に関わる処理だけを集めて、役割をはっきりさせようとする指標。

💡AIワンポイント

高凝集の単位で依頼すると、AIが参照すべきファイルが自然に絞られます。レビューでも「この責務から逸れていないか」を1軸で判定でき、差分判断が速くなります。

詳しく見る

結合度（Coupling） C

Coupling

モジュールどうしがどれくらい強くつながっているかを表す指標で、弱くつながっているほど変更やテストが楽になる。

💡AIワンポイント

結合度が高いままAIに修正させると、関係ないモジュールまで連鎖変更しがちです。依存の向きと接点を先に示すと、影響範囲の暴走を抑えられます。

詳しく見る

D

DIP（依存性逆転の原則） D

Dependency Inversion Principle

具体的なクラスではなくインターフェースなどの抽象に依存させて、仕組みを差し替えやすくする設計原則。

💡AIワンポイント

DIPを守ると、AIは具体クラスではなく契約に沿って修正案を出せます。レビューではimportが実装型に逆戻りしていないかを見るだけで設計崩れを早期検知できます。

DI（依存性注入） D

Dependency Injection

クラスが自分で new せず、必要なオブジェクトを外から受け取ることで、差し替えやテストをしやすくする設計のやり方。

💡AIワンポイント

DIを使うと、AIへの依頼で「差し替える実装」と「触らない呼び出し側」を明確に分離できます。テストダブルを前提に生成させると検証も自動化しやすくなります。

DRY（重複の排除） D

Don't Repeat Yourself

同じ意味の処理や知識をあちこちにコピペせず、1か所にまとめて管理しようとする設計の考え方。

💡AIワンポイント

AIは「一箇所直して」と言われても、同じコードが別の場所にあると気づかないことがあります。DRYを徹底することは、AIによる修正漏れ（デグレード）を防ぐ最強の防御策です。

DSL（ドメイン固有言語） D

Domain-Specific Language

特定の分野の問題を簡潔に表現するために作られた専用の言語。設定ファイルやビルドスクリプトなどでよく使われる。

💡AIワンポイント

DSLをAIで設計する際は、許可する文法と禁止構文を最初に示します。曖昧な記法を残すと生成器側で解釈差が出るため、例文ベースでレビューするのが有効です。

デプロイ D

Deployment

ビルドした成果物をサーバーやストアなど本番やテスト環境に配置し、ユーザーが使える状態にする作業。

💡AIワンポイント

デプロイ手順をAIに作らせるときは、ロールバック条件と判定メトリクスを必ず対で記述します。本番反映より先に「戻し方」を確定させるのが事故予防になります。

ドメイン D

Domain

ソフトウェアが扱う業務や問題の世界のこと。ユーザーやビジネスのルールを表すモデルの範囲を指す。

💡AIワンポイント

ドメイン語彙を揃えてからAIに依頼すると、命名と振る舞いのズレが減ります。ユビキタス言語にない語を差分で見つけたら、設計崩れのサインとして扱えます。

詳しく見る

依存 D

Dependency

あるコードが別のコードに頼って動く関係のこと。依存が多すぎたり強すぎると変更やテストが難しくなる。

💡AIワンポイント

依存関係の可視化なしでAIに改修を頼むと、循環参照を作り込みやすくなります。依存グラフを添えて「追加禁止の辺」を指定すると設計破綻を防げます。

宣言型 D

Declarative Style

何をどう実行するかではなく「どんな状態になってほしいか」を記述する書き方。SQL や CSS のように結果を宣言して任せる。

💡AIワンポイント

AIは「手順（How）」を指示されるより「あるべき姿（What）」を提示される方が、ロジックの破綻が少ないコードを生成できます。htmxのような宣言型技術はAI時代の最適解の一つで、AIは複雑なJSロジックを生成せずに済むため、バグ混入率を劇的に下げられます。

死蔵コード D

Dead Code

もう使われていないのに、実際には呼ばれずに残り続けているコード。読み手を混乱させ、誤使用やバグの原因にもなりやすい。

💡AIワンポイント

死蔵コードを残すと、AIが古い分岐を根拠に誤修正する原因になります。削除候補をテストカバレッジと参照解析で確定してから一括整理するのが安全です。

設計 D

Design

決めた要件をもとに、画面や処理の流れ、データの形などソフトウェアの作りを具体的な形に落とし込む工程。

💡AIワンポイント

設計段階で境界とデータ流れを図解して渡すと、AIは局所最適なつぎはぎ実装をしにくくなります。レビューでも設計逸脱を差分単位で判定しやすくなります。

駆動 D

Driven

テスト駆動やイベント駆動のように、何かをきっかけにして設計や処理の流れを決めるという意味合いで使われる言葉。

💡AIワンポイント

〜駆動の設計は、起点イベントを明確にしないとAIの実装が散らばります。トリガー、入力、完了条件を1セットで渡すと自動化フローが安定します。

E

カプセル化 E

Encapsulation

データとそれを扱う操作を1つにまとめ、外から直接いじらせずメソッド経由で扱わせて安全にする考え方。

💡AIワンポイント

カプセル化が弱いコードにAIを入れると、内部状態へ直接アクセスする差分が混ざります。公開API以外は変更禁止と明示して生成させると事故を抑えられます。

詳しく見る

F

フェールセーフ F

Fail-safe

障害や誤操作が起きたときに、人やシステムにとってより安全な状態になるように設計しておく考え方。

💡AIワンポイント

フェールセーフでは、異常時に必ず安全側へ倒れる条件をコードで固定します。AI生成後は例外経路で危険動作が残っていないかを重点レビューします。

フェールソフト F

Fail-soft

障害が起きても機能を一部だけ制限し、性能を落としながらも最低限のサービスを続けるようにする振る舞い。

💡AIワンポイント

フェールソフトは「壊れても続ける範囲」を先に決めてAIに実装させます。機能縮退時のユーザー通知まで含めて設計すると、障害時の混乱を抑えられます。

フォールトトレランス F

Fault Tolerance

一部で故障やエラーが起きても、全体としてはサービスを継続できるように設計しておく考え方。

💡AIワンポイント

フォールトトレランスを実装させる際は、許容する失敗と停止条件を先に定義します。AIが無限リトライを入れていないか確認するだけで事故を大きく減らせます。

フレームワーク F

Framework

アプリ開発の土台となる共通機能と枠組み。決められた場所にコードを書くことで基本的な処理が手に入る。

💡AIワンポイント

フレームワーク案件でAIを使うときは、約束された拡張点だけ触らせると安定します。ライフサイクル外で独自処理を足していないかを必ず確認します。

フールプルーフ F

Fool-proof

ユーザーがうっかり間違った操作をしても重大な問題になりにくいように、そもそも誤操作しづらく設計しておく工夫。

💡AIワンポイント

フールプルーフは、AIにUI改善を頼むときほど効果が出ます。誤操作パターンを先に列挙しておけば、確認ダイアログや入力制約を過不足なく組み込めます。

関数 F

Function

入力を受け取り結果を返す、小さな処理のまとまり。名前を付けて再利用でき、副作用が少ないほど理解しやすくなる。

💡AIワンポイント

関数単位でAIに依頼するときは、入力・出力・副作用の3点を固定します。副作用なし関数を増やすほど、生成物の検証はスナップショット中心で高速化できます。

G

グルー G

Glue Code

本体の部品どうしや外部システムをつなぐためだけに書かれる橋渡し用のコード。増えすぎると構造が分かりにくくなる。

💡AIワンポイント

グルーコードは増えるほどAIの探索コストが上がります。接続責務だけに限定し、業務判断を混ぜないルールで整理すると改修精度が保てます。

H

HATEOAS(ヘイトオス) H

Hypermedia as the Engine of Application State

サーバーがレスポンスの中に「次に何ができるか（リンクやボタン）」を含めて返す仕組み。クライアント側で次に叩くAPIを知っておく必要がなくなります。

💡AIワンポイント

AIエージェントがアプリを自律的に操作する際、事前に複雑なAPI仕様を学習していなくても、サーバーから送られてきたHTMLを辿るだけで正しく機能を利用できるようになります。

フック H

Hook

処理の途中で外部のコードを挟み込めるよう用意された「引っかけるポイント」。イベントや拡張でよく使われる。

💡AIワンポイント

フックは便利ですが、AIが副作用の強い処理を差し込みやすい場所でもあります。実行順と再入可否を条件化して依頼すると、予期しない連鎖障害を防げます。

ヘルスチェック H

Health Check

アプリやサーバーが生きているかを外から定期的に確認する仕組み。ロードバランサが異常なサーバーを外すときなどに使う。

💡AIワンポイント

ヘルスチェックは生存確認だけでなく依存先劣化の検知まで設計すると実運用で効きます。AIにはlivenessとreadinessを分けて実装させるのが定石です。

I

IoC（制御の反転） I

Inversion of Control

処理の流れの主導権をアプリ側ではなくフレームワークなどに持たせ、必要な部分だけ自分のコードを書く考え方。

💡AIワンポイント

IoC前提のコードでは、AIに「差し込む処理」だけ依頼しやすくなります。実行順序をフレームワークに任せる分、独自制御を混ぜていないかの確認が重要です。

インターフェース I

Interface

部品どうしがどんなメソッドでやり取りするかを決める「窓口」の定義。中身を隠して差し替えやすくする。

💡AIワンポイント

インターフェース先行で依頼すると、AIは実装詳細に引っ張られずに提案できます。戻り値契約と例外契約を先に固定すると、後工程の統合不具合が減ります。

J

JSON J

JSON

データをキーと値の組み合わせで表すテキスト形式。人間にも読みやすく、多くの Web API や設定ファイルで標準的に使われている。

💡AIワンポイント

JSONをAIに生成させるときは、必須キーと型をスキーマで先に縛ります。自由文だけで指示するとnull混入や型揺れが起きやすく、後段処理の不具合源になります。

K

KISS（シンプルに保つ） K

Keep It Simple, Stupid

必要なことだけをシンプルに実装し、余計な仕組みや複雑さを足さないようにする設計の考え方。

💡AIワンポイント

複雑なコードはAIも誤読します。「AIならこれくらい読めるだろう」と甘えず、KISSを貫くことが、結果として最もAIに愛されるコードになります。

カーネル K

Kernel

OSの中核となる部分で、CPUやメモリ、ディスクなどのハードウェア資源を管理し、アプリからの要求を仲立ちする。心臓部にあたる存在。

💡AIワンポイント

カーネル周辺をAIで扱うときは、権限境界と失敗時の影響範囲を必ず明示します。ユーザー空間へ逃がせる処理を切り分ける設計が安全性を高めます。

L

LoB(振る舞いの局所性) L

Locality of Behavior

「あるコードの一部を見ただけで、その挙動が完全に理解できる」という性質のこと。htmxのように、HTMLの中に直接挙動（hx-getなど）を書くスタイルは、このLoBを極限まで高めます。

💡AIワンポイント

AIにコードを修正させる際、関連するJSやCSSファイルをあちこち探させる必要がなく、その箇所のHTMLを渡すだけで正確な修正案が出るため、AIとの共創効率が劇的に上がります。

LOC L

LOC (Lines of Code)

Line of Code の略で、ソースコードの行数を表す指標。規模の目安にはなるが、多ければ良い・少なければ良いとは限らない。

💡AIワンポイント

LOCはAI生成量の管理指標として使えますが、短さだけで評価すると危険です。行数ではなく責務密度と重複率を合わせて見ると、改善判断を誤りにくくなります。

ライブラリ化 L

Library-ization

よく使う機能を1つのライブラリとしてまとめ、他のプロジェクトから簡単に再利用できるようにすること。

💡AIワンポイント

ライブラリ化の依頼では、公開範囲とバージョニング方針を同時に示すとぶれません。内部ユーティリティを公開APIに混ぜないレビューが重要です。

レイヤー L

Layer

システムを役割ごとの層に分けて積み重ねる考え方。表示、業務ロジック、データアクセスなどを分けやすくする。

💡AIワンポイント

レイヤー設計では「どの層まで変更可か」を依頼時に宣言すると、AIの越境実装を防げます。レビューはビジネスロジックがUI層へ漏れていないかを重点確認します。

疎結合 L

Loose Coupling

モジュール同士ができるだけ少ない情報だけでつながる状態。お互いの変更の影響を小さくできる。

💡AIワンポイント

モジュール同士が疎結合であれば、AIに「この機能だけ切り出して直して」と頼む際のトークン（文脈）を最小限に抑えられ、回答の精度が上がります。

詳しく見る

M

メカニズム M

Mechanism

仕組みの具体的な動き方や実現方法のこと。何をするかを決めるポリシーと分けて考えると整理しやすい。

💡AIワンポイント

メカニズムはAIが最適化しやすい領域ですが、方針を混ぜると設計が濁ります。「何をするかは別層」を明示して依頼すると、差し替え可能な実装を保てます。

メトリクス M

Metrics

レスポンスタイムやエラー率、CPU使用率など、システムの状態や品質を数字として継続的に計測・監視するための指標。

💡AIワンポイント

メトリクス設計を先にAIへ任せると、実装後の評価軸がぶれません。閾値とアラート優先度を決めておくと、自律運用時の誤検知対応が安定します。

モジュール M

Module

関連する処理やデータをひとまとまりにした単位。クラスやファイル、パッケージなどがモジュールに当たる。

💡AIワンポイント

モジュール境界を明記してAIに渡すと、修正の波及を小さく保てます。公開関数以外を触っていないかをレビュー観点にすると、再利用性を守りやすくなります。

保守 M

Maintenance

運用中のシステムに対して、バグ修正や性能改善、仕様変更への対応などを行い、使い続けられるようにする活動。

💡AIワンポイント

保守タスクは既存挙動を守る回帰観点を先に渡すと、AIの過剰最適化を防げます。変更理由ごとにPRを分ける運用にすると、レビュー負荷が安定します。

O

OCP（オープン・クローズドの原則） O

Open-Closed Principle

新しい振る舞いを追加しやすくしつつ、既存コードの変更はできるだけ少なくしようとするオブジェクト指向の設計原則。

💡AIワンポイント

OCPを意識した依頼では、新機能を既存分岐へ直書きしない条件を明記します。拡張ポイント追加で要件を満たせるかを見ると、将来変更のコストを抑えられます。

OSS O

Open Source Software

Open Source Software の略。ソースコードが公開され、誰でも閲覧・改良・再配布できるライセンスのソフトウェアを指す。

💡AIワンポイント

OSS活用では、AIに依存更新を任せる前にライセンス条件とメンテ状況を確認します。採用理由を記録しておくと、将来の置き換え判断が速くなります。

運用 O

Operations

リリースしたシステムを日々監視し、ジョブ実行や設定変更、問い合わせ対応などを行って安定して動かし続けること。

💡AIワンポイント

運用系の自動化をAIに任せるなら、通知閾値と一次対応手順を同じプロンプトで渡します。異常検知だけ作って復旧導線がない状態を避けるのがポイントです。

P

POSIX P

POSIX

UNIX系OSでプログラムが同じように動くように決めた標準仕様。POSIX対応にしておくと、別のUNIX系環境に移植しやすくなる。

💡AIワンポイント

POSIX準拠でスクリプトを書くと、AIが提案した運用手順を環境間で再利用しやすくなります。非互換オプションを排除するだけで本番差異の事故を減らせます。

プラガブル P

Pluggable

プラグインのように部品をあとから差し替えたり追加したりできる設計になっている状態を指す言葉。

💡AIワンポイント

プラガブル設計では、差し替え単位を先に固定してAIに渡すと設計がぶれません。実装を増やしても既存呼び出し側を変更しないことを確認します。

プラグイン P

Plugin

本体のソフトにあとから追加して機能を拡張できる小さなモジュール。オンオフや追加がしやすい形で作られる。

💡AIワンポイント

プラグイン実装をAIに任せるなら、契約インターフェースと無効化時の挙動まで指定します。本体改変なしで着脱できるかがレビューの合格ラインです。

プログラミング P

Programming

設計どおりにコンピュータが動くよう、プログラミング言語を使ってソースコードを書いたり修正したりする作業。

💡AIワンポイント

実装依頼では、変更対象ファイルと許可するAPI名を最初に列挙すると誤編集が減ります。コード生成後は「動くか」より「制約を守っているか」を先に確認するのが安全です。

プロダクト P

Product

ユーザーに価値を届ける製品やサービス全体のことで、ソフト本体だけでなく周辺の仕組みや体験も含めて指す。

💡AIワンポイント

プロダクト視点でAIを使うなら、機能追加より計測設計を先に依頼するのが有効です。価値指標がないまま生成を進めると、出荷後の改善サイクルが回りません。

ポリシー P

Policy

「何をしたいか」という方針やルールのこと。メカニズムが「どう実行するか」を担当するのと対になる考え方。

💡AIワンポイント

ポリシーを先に文章化して渡すと、AIは実装候補を目的に沿って絞れます。レビューでは条件分岐が方針を漏れなく表現しているかを重点的に確認します。

手続き P

Procedure

値を返すことよりも、一連の処理を順番に実行することに意味がある関数。画面更新やファイル書き込みなどに使われる。

💡AIワンポイント

手続き型の処理は順序依存バグが出やすいため、AIには前提状態と終了状態を明示します。途中失敗時の巻き戻し手順まで書かせると運用事故を減らせます。

驚き最小の原則 P

Principle of Least Surprise

利用者が「そう動くだろう」と自然に予想できる挙動にそろえ、思わぬ動きで驚かせないように設計しようという原則。

💡AIワンポイント

驚き最小の原則を守ると、AIが既存慣習に沿った提案をしやすくなります。命名・引数順・エラー文言の不意打ちを減らすことがレビュー効率に直結します。

R

RB R

RB (tool / technique)

Review Board など、コードレビューや開発ツール名の略称として使われることが多い略語。文脈によって意味が変わる。

💡AIワンポイント

RB運用では、AI提案をそのまま通さずレビュー観点テンプレートで機械的に検査します。設計逸脱・例外処理・後方互換の3点を固定すると品質が安定します。

リファクタリング R

Refactoring

外から見た振る舞いは変えずに、コードの構造や名前付けを整理して読みやすく、変更しやすくする改善作業。

💡AIワンポイント

リファクタリング依頼では「振る舞い不変」を例付きで固定すると、AIが機能変更を混ぜにくくなります。差分レビューは命名変更と構造変更を分けて確認すると安全です。

詳しく見る

ロバストネス R

Robustness

予期しない入力や多少の負荷変動でも簡単には落ちず、安定して動き続けられる強さを指す言葉。

💡AIワンポイント

ロバストネス強化では、異常入力の扱いを具体例付きでAIに渡すと効果的です。境界値とタイムアウト処理を先に検証すると、現場障害の再発率を下げられます。

ロールバック R

Rollback

障害や不具合が出たときに、データやシステムの状態を直前の正常なバージョンまで戻す操作や仕組み。

💡AIワンポイント

ロールバック手順はAIに書かせる前に、復旧対象と許容停止時間を決めます。DBとアプリの戻し順が一致しているかをチェックリスト化すると実行が安全です。

冗長化 R

Redundancy

サーバーや回線などを複数用意し、どれかが故障しても残りで動かせるようにする設計。止まりにくいシステムを作るための工夫。

💡AIワンポイント

冗長化は台数追加だけでは不十分で、切替条件までAIに明示する必要があります。片系障害時に整合性を崩さない設計かをレビューの最優先に置きます。

要件定義 R

Requirements Definition

システムで何を実現したいかを整理し、必要な機能や条件を言葉でまとめて関係者で合意する作業。

💡AIワンポイント

AIに実装を頼む前に、要件を「達成条件・非対象・失敗時挙動」の3点で固定すると手戻りが減ります。要件定義の質が、そのまま生成コードの品質上限になります。

S

SLAP（単一抽象化レベルの原則） S

Single Level of Abstraction Principle

1つの関数の中では同じ抽象度のことだけを書くようにし、細かい処理は別の関数に分けようとする考え方。

💡AIワンポイント

SLAPを守ると、AI生成コードの可読性が急に上がります。1関数内で抽象レベルが混在していたら、分割提案を再依頼するだけでレビュー時間を短縮できます。

SRP（単一責任の原則） S

Single Responsibility Principle

クラスや関数には1つの役割だけを持たせ、変更の理由ができるだけ1種類になるように分けて設計しようという原則。

💡AIワンポイント

1リクエスト1責務でAIに渡すと、生成差分が小さく再レビューが安定します。SRPは実装原則というより、AI協業時のタスク分割ルールとして効きます。

詳しく見る

サービスロケータ（アンチパターン） S

Service Locator

必要なオブジェクトを共有窓口から取得する仕組みだが、依存関係が見えにくくなりテストしづらくなりがちなパターン。

💡AIワンポイント

Service Locatorは依存がコード上に現れにくく、AIが不足コンテキストのまま修正しがちです。コンストラクタ注入へ寄せるだけで、生成精度とレビュー可能性が一段上がります。

シェル S

Shell

ユーザーがOSに命令するための窓口となるプログラム。コマンドを入力して実行したり、スクリプトで処理を自動化したりできる。

💡AIワンポイント

シェル自動化をAIに任せる場合、set -euo pipefail相当の失敗方針を先に指定します。入力検証とログ出力先を固定すると運用時の追跡が容易になります。

シグネチャ S

Signature

関数名・引数・戻り値の型など、その関数がどのように呼ばれるかを表す情報。関数の「名刺」にあたる部分。

💡AIワンポイント

シグネチャはAI協業の契約書です。引数名と戻り値の意味を先に固定すれば、内部実装を何度作り直しても呼び出し側の修正を最小にできます。

スキーマ S

Schema

データの項目名や型、制約など、データの構造を決めた設計図。データベースやJSONの定義などで使われる。

💡AIワンポイント

スキーマ変更をAIに任せるときは、互換性ルールと移行手順を同時に渡します。NULL可否や制約名までレビュー対象にすると、本番移行時の事故を減らせます。

ストレステスト S

Stress Test

通常より重い負荷や長時間の利用をかけて、システムがどこまで耐えられるかや、限界付近でどう振る舞うかを確認するテスト。

💡AIワンポイント

ストレステストはAIにシナリオ生成させると効率化できますが、負荷モデルの根拠を添えることが必須です。ピーク時のボトルネックを再現できる条件を先に固定します。

T

テスト T

Testing

作ったソフトが期待どおりに動くかを確認する工程で、バグを見つけて修正し、品質や安心感を高めるために行う。

💡AIワンポイント

テストを同時生成させるときは、正常系より先に失敗系ケースを指定すると穴が減ります。AIの提案は通過結果だけでなく、未検証シナリオの有無まで確認します。

テンプレート化 T

Templating

似た構造の処理や文書をひな形として切り出し、差分だけを埋めて再利用しやすくすること。

💡AIワンポイント

テンプレート化は、AIへの入力を定型化できる点が強みです。可変項目だけを表で渡せば、文面生成やコード生成の揺れを大きく減らせます。

トレース T

Trace

リクエストがどのサービスや処理を通ったかをたどれるようにする情報。分散システムでの原因調査に役立つ。

💡AIワンポイント

トレースIDの受け渡し規約を明示してAIに実装させると、障害の因果追跡が一気に楽になります。ログとメトリクスを同一IDで結べるかをレビューで確認します。

U

UNIX U

UNIX

昔から使われているOSの一族で、シンプルな仕組みと小さなコマンドを組み合わせる思想が特徴。LinuxやmacOSの元になった文化的な基盤。

💡AIワンポイント

UNIXの思想で小さいコマンドに分けると、AIにも修正依頼を分割しやすくなります。1機能1責務のツール連携は、自動化失敗時の切り分け速度を上げます。

V

verbose V

Verbose

ログやメッセージを詳しく大量に出すモード。デバッグには便利だが、普段はノイズになるため切り替えて使うのが一般的。

💡AIワンポイント

verboseログはAIデバッグ時の観測点として有効ですが、常時有効だとノイズになります。切替条件と出力粒度を先に決めると、障害調査の往復が短くなります。

Y

YAGNI（今は要らない） Y

You Aren't Gonna Need It

将来使うかもしれない機能を今から作らず、本当に必要になったときにだけ追加しようとする考え方。

💡AIワンポイント

AIに将来拡張まで先回り実装させると、未使用分岐が増えてレビューが難化します。今必要な仕様だけ渡し、追加は次チケットに分けると破綻を防げます。