アーキテクチャ専門用語集（英数字・五十音順）― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の専門用語リファレンスです。各記事内にも初出用語には1行解説を添えているため、毎回ここに戻る必要はありません。全体を俯瞰したいとき・関連記事を探したいときの索引としてご利用ください。

ボリュームが多いためブラウザの検索機能（Ctrl+F / Cmd+F）での検索が効率的です。

flowchart LR
    USE([記事を読んでいて<br/>用語が分からない]) --> CHECK{各記事内に<br/>1行解説あり?}
    CHECK -->|あり| INLINE[本文中の<br/>カッコ書きで理解]
    CHECK -->|なし or 全体俯瞰| ALPHA[英数字 A-Z<br/>から検索]
    CHECK -->|なし or 全体俯瞰| KANA[日本語<br/>五十音順から検索]
    INLINE --> CONTINUE([記事を続ける])
    ALPHA --> RELATED[関連記事リンク<br/>から深掘り]
    KANA --> RELATED
    RELATED --> CONTINUE
    classDef start fill:#fef3c7,stroke:#d97706;
    classDef inline fill:#dbeafe,stroke:#2563eb;
    classDef ref fill:#fae8ff,stroke:#a21caf;
    class USE start;
    class INLINE,CONTINUE inline;
    class ALPHA,KANA,RELATED ref;

各カテゴリの概要記事

英数字（A-Z）

A

• A11y ― Accessibility（アクセシビリティ）の略で、「a」と「y」の間に11文字あることから A11y と表記される。視覚・聴覚・運動機能などに制約のあるユーザーも含め、誰もがWebを使える状態を指す。スクリーンリーダー対応、キーボードのみでの操作可能性、十分なコントラスト比、画像の代替テキスト等が代表要素。米国ADA法や欧州EAA法など法規制の対象にもなっており、企業サイトでは設計初期から考慮が必要
• ABAC ― Attribute-Based Access Control（属性ベースアクセス制御）。ユーザーの部署・役職・所在地・時間帯やリソースの機密区分など複数の属性を組み合わせて、動的に認可を判定するモデル。ポリシーを XACML や OPA（Rego）で宣言的に記述し、RBACでは表現しにくい複雑な条件（「営業時間中に本社IPからのみ参照可」等）を扱える。柔軟性が高い反面、ポリシー設計と運用負荷は重く、適用範囲を絞ることが多い
• ACID ― Atomicity（原子性）・Consistency（一貫性）・Isolation（独立性）・Durability（永続性）の頭字語。RDBが提供する整合性保証の4性質で、銀行残高や在庫など「絶対にズレてはいけないデータ」を扱う処理の前提となる。複数の更新を1つの単位として全成功か全失敗にし、同時実行があってもお互いに影響を与えず、コミット後はクラッシュしても消えない、という強い保証を意味する
• AD ― Active Directory。Microsoft が提供する社内ID・認証基盤で、Windows ドメインのユーザー・グループ・PC・グループポリシーを統合管理する。多くの日本企業のオンプレミス環境で標準採用されており、近年はクラウド版の Azure AD（現 Microsoft Entra ID）と併用されるハイブリッド構成が主流。SSO・MFA・条件付きアクセスの基盤になる
• ADM ― Architecture Development Method。EAフレームワークの代表格 TOGAF が定義する、A〜H の8フェーズからなる段階的な進め方。ビジョン定義 → ビジネス・データ・アプリ・技術アーキテクチャの設計 → 移行計画 → 実装ガバナンスという順で全社IT変革を進める。重厚で大企業向けだが、考え方は中規模プロジェクトでも参考になる
• ADR ― Architecture Decision Record。「なぜその設計を選んだか」を1ファイル1判断で短く文書化する慣行で、Markdown で Git リポジトリに置くのが一般的。半年後に「これなぜこうなってる？」となる事故を防ぐ目的で、決定事項・背景・検討した代替案・トレードオフを残す。再考時にも判断の前提条件を追跡できる
• APM ― Application Performance Monitoring。アプリケーションのレスポンス時間・スループット・エラー率や、リクエスト経路上のどこが遅いかを可視化するツール群。代表例は Datadog APM、New Relic、Dynatrace、AWS X-Ray など。分散トレーシング・コードレベルプロファイリング・例外集約を統合的に提供し、性能トラブル時の原因特定までの時間を大きく短縮する
• AuthN / AuthZ ― Authentication（認証＝「あなたは誰か」を確認する）と Authorization（認可＝「あなたは何をしてよいか」を判定する）の略。よく混同されるが別概念で、認証はパスワード・MFA・パスキーなどで本人確認、認可は RBAC や ABAC などで権限判定を行う。OAuth は認可、OIDC は認証、と区別すると整理しやすい

B

• BA / DA / AA / TA ― Business / Data / Application / Technology Architecture の4層で、エンタープライズアーキテクチャ（EA）の標準的な構造化視点。業務プロセス（BA）→ 取り扱うデータ（DA）→ それを実現するアプリ（AA）→ 動かす基盤（TA）と上から下へ整合させる考え方。TOGAF などのフレームワークで明確に定義されており、全社IT地図を描く際の共通言語になる
• BASE ― Basically Available（基本的に使える）, Soft state（状態は変動しうる）, Eventual consistency（結果整合性）の頭字語。ACID の対極にある分散NoSQLの一貫性モデルで、可用性とスケーラビリティを優先しつつ、一時的な不整合を許容する。Amazon DynamoDB や Cassandra などの世代で広く採用されている考え方
• BCP ― Business Continuity Plan（事業継続計画）。地震・サイバー攻撃・大規模障害等で業務が止まった際に、どの業務を・どの順で・どこまで復旧させるかを事前に決めておく計画。RPO（許容データ損失）と RTO（許容停止時間）を業務単位で定義し、バックアップ戦略・DR サイト構成・代替手順とセットで設計する
• BFF ― Backend for Frontend。フロントエンド専用に置く薄いサーバー層で、複数のマイクロサービスから取得したデータを画面に最適化された形に集約・整形する。モバイルアプリとWebで必要なデータ形が違う場合に、それぞれ専用 BFF を置くことで本体APIを汚さずに最適化できる。GraphQL や tRPC との相性が良い
• Blue/Green デプロイ ― 本番（Blue）と同じ構成の待機環境（Green）を別途用意し、新バージョンを Green 側に展開してからルーティングを一気に切り替えるリリース手法。問題発生時はルーティングを戻すだけで瞬時にロールバックでき、ダウンタイムも理論上ゼロにできる。代償として一時的にインフラが2倍必要
• Bounded Context ― DDD（ドメイン駆動設計）の中核概念で、特定の用語・モデルが一貫した意味を持つ境界を指す。例えば「顧客」という言葉も営業文脈と請求文脈では別物として扱う、という割り切り。マイクロサービスの分割単位の判断基準としても用いられ、不適切な切り方を防ぐ羅針盤になる
• BPMN ― Business Process Model and Notation。業務プロセスを開始・終了・タスク・分岐・並行などの記号で表現する国際標準記法（OMG策定）。業務側と開発側が同じ図を見ながら要件を確定するための共通言語として、業務システム・ワークフロー設計で広く使われる

C

• CAP 定理 ― 分散システムでは Consistency（一貫性）・Availability（可用性）・Partition-tolerance（ネットワーク分断耐性）の3つを同時には満たせないという、Eric Brewer による定理。ネットワーク分断は実環境では避けられないため、現実は「CP寄り」か「AP寄り」かのトレードオフ選択になる。NoSQL選定や分散DB設計の前提知識
• CDC ― Change Data Capture。DBのトランザクションログから変更（INSERT/UPDATE/DELETE）をリアルタイムに抽出し、別システムへストリーミングする技術。Debezium・AWS DMS・Fivetran HVR などが代表で、データウェアハウス連携・キャッシュ無効化・マイクロサービス間のデータ同期に使われる。アプリ側を変更せずに変更を伝播できるのが強み
• CDN ― Content Delivery Network。世界中に配置されたエッジサーバーから利用者に近い拠点でコンテンツを配信し、レイテンシ削減と原本サーバーの負荷軽減を実現する仕組み。CloudFront・Cloudflare・Akamai・Fastly が代表。静的ファイルだけでなく、API キャッシュ・WAF・エッジ関数の実行基盤としても使われる
• CI / CD ― Continuous Integration（継続的結合）と Continuous Delivery / Deployment（継続的デリバリー／デプロイ）。CI はプッシュ毎に自動でビルド・テストを回して「壊れた状態を早期検知」する活動、CD はその先のステージング・本番までの自動配信を指す。GitHub Actions・GitLab CI・CircleCI・Jenkins が代表ツールで、現代開発のデファクト
• CIO / CDO / CTO / CISO ― Chief Information / Data / Technology / Information Security Officer。経営層の IT 関連役職で、CIO は社内IT全般、CDO はデータ戦略、CTO は技術戦略・プロダクト技術、CISO は情報セキュリティを統括する。組織によって境界はあいまいで、CTO がアーキテクチャ最終責任を持つ場合と、別途 Chief Architect を置く場合がある
• Clean Architecture ― Robert C. Martin（Uncle Bob）が提唱した、依存方向を内側のドメイン層に向けて制御するアーキテクチャパターン。同心円の内側にエンティティ・ユースケース、外側にUI・DB・フレームワークを配置し、外側が内側に依存するルールを徹底する。フレームワーク差し替えやテスト容易性に強いが、規模に対して過剰になりやすく適材適所
• CNCF ― Cloud Native Computing Foundation。Linux Foundation 傘下の業界団体で、Kubernetes・Prometheus・Envoy・etcd・Helm 等クラウドネイティブ技術の標準化とエコシステム育成を担う。プロジェクトを Sandbox → Incubating → Graduated と段階管理しており、技術選定の信頼性指標としても参照される
• Conway の法則 ― 「システムを設計する組織は、その組織のコミュニケーション構造をそのまま反映した設計を生み出す」という Melvin Conway による経験則。3チームで作ると3層構造のシステムができる、という現象を指し、逆に「望ましいアーキテクチャに合わせて組織を変える」逆コンウェイ戦略も提案されている
• CORS ― Cross-Origin Resource Sharing。異なるオリジン（プロトコル＋ドメイン＋ポート）間のJSリクエストを、ブラウザがプリフライト方式で制御するセキュリティ仕組み。サーバ側が Access-Control-Allow-Origin 等のヘッダで明示的に許可しないと拒否される。フロントエンド開発でハマる代表トラブルの一つ
• CQRS ― Command Query Responsibility Segregation。書き込み（Command）と読み取り（Query）でモデル・ストレージを分離する設計パターン。読み取り側を非正規化したリードモデルにすることで参照性能を最適化でき、Event Sourcing と組み合わせて使われることが多い。複雑性が増すので、本当に必要な集約のみに適用するのが鉄則
• CSP ― Content Security Policy。ブラウザにスクリプト・スタイル・画像等の読み込み元を制限させる HTTP レスポンスヘッダ。XSS の影響を大幅に抑える防御策で、script-src 'self' のように許可元を列挙する。設定ミスで正規スクリプトまでブロックして画面が壊れるため、レポートモードで段階導入するのが定石
• CSR ― Client Side Rendering。サーバーは空に近い HTML と JS バンドルを返し、ブラウザ側で JS を実行して画面を組み立てる方式。React や Vue の SPA が代表で、画面遷移の体感速度が速い反面、初回表示・SEO・低スペック端末での表示開始の遅さが弱点
• CSRF ― Cross-Site Request Forgery。ログイン中のユーザーを罠サイトに誘導し、本人の意図しない操作（送金・パスワード変更等）を行わせる攻撃。対策として CSRF トークンの埋め込み、SameSite Cookie、Origin/Referer 検証などが標準。フォーム送信のあるWebアプリは必ず対処が必要
• CVE / CVSS ― CVE は Common Vulnerabilities and Exposures（共通脆弱性識別子）で、各脆弱性に CVE-2024-XXXX 形式の世界共通IDを付与する制度。CVSS は Common Vulnerability Scoring System で、深刻度を 0.0〜10.0 で数値化する評価基準。脆弱性管理ツールやニュースで多用される基本単位

D

• DAG ― Directed Acyclic Graph（有向非巡回グラフ）。矢印（依存方向）が一方向に流れ、循環がないグラフ構造。Airflow のジョブワークフロー、分散トレースのスパン構造、ビルドツールの依存解決など、「順序のある依存関係」を扱う場面で頻出する基本データ構造
• DAST ― Dynamic Application Security Testing。実際にアプリを動かし、外部から HTTP リクエストを送って脆弱性を検出する手法。OWASP ZAP・Burp Suite・Nikto などが代表ツールで、SAST（静的解析）が見落とす実行時の問題を補完できる。本番ではなくステージング環境に対して定期実行するのが基本
• DDD ― Domain-Driven Design（ドメイン駆動設計）。Eric Evans の同名書籍に基づき、業務知識（ドメイン）をコードの第一級市民として扱う設計思想。Ubiquitous Language（業務側と開発側で共通の用語）、Bounded Context、Aggregate、Repository などの戦術パターンを組み合わせる。複雑な業務システムで真価を発揮する
• DDoS ― Distributed Denial of Service。多数の端末（ボットネット）から一斉にリクエストを送り、サービスを停止に追い込む攻撃。CDN・WAF・専用緩和サービス（AWS Shield・Cloudflare）で吸収するのが定石で、アプリ側のスケーリングだけでは対処不能なほどの帯域・PPS で殺到する
• DNS ― Domain Name System。ドメイン名を IP アドレスに変換する分散型のディレクトリサービス。階層構造（ルート → TLD → 権威サーバー）で名前解決を行い、TTL によりキャッシュされる。「DNS変更が反映されない」はTTLとキャッシュの理解で大半が解決する基本知識
• Docker ― コンテナ仮想化を一般化した代表的なツールで、アプリケーションと依存ライブラリ・OS設定を1つのイメージにまとめて配布できる。「自分の環境では動くのに本番で動かない」を解消した革命的技術で、Kubernetes など現代インフラの基盤になっている。Dockerfile・Compose・レジストリが基本概念
• DR ― Disaster Recovery（災害復旧）。地震・大規模障害・データセンター喪失などの致命的事象から、データとシステムを復旧する取り組み全般。BCP がビジネス全体の継続計画なのに対し、DR は IT に焦点を絞る。マルチリージョン構成、定期的なフェイルオーバー訓練、RTO/RPO の設定が中核
• DWH ― Data Warehouse（データウェアハウス）。業務システムから抽出したデータを分析しやすい形に統合・蓄積する基盤。Google BigQuery・Snowflake・Amazon Redshift・Databricks が代表で、列指向ストレージと分散実行で大規模集計を高速化する。BI ツールやレポート、データサイエンスの土台になる

E

• EA ― Enterprise Architecture（エンタープライズアーキテクチャ）。企業全体のIT資産・業務プロセス・データ・技術基盤を体系的に整理し、経営戦略と整合させる活動。BA/DA/AA/TA の4層で表現し、TOGAF・Zachman・FEA などのフレームワークが代表。中長期の IT 投資判断の基盤になる
• EDA ― Event-Driven Architecture。サービス間を直接呼び出すのではなく、イベント（「注文が確定した」等の事実）の発信／受信で疎結合に連携する構造。Kafka・Kinesis・Pub/Sub などのメッセージング基盤が前提となる。スケーラビリティと耐障害性に優れる反面、デバッグや整合性確保が難しい
• ELT ― Extract, Load, Transform。データを先にDWHへロードしてから変換する方式で、クラウドDWHの計算力を活用するのが時代の流れ。dbt（Data Build Tool）の普及で SQL ベースの Transform が標準化された。ETL 時代の「ロード前に整える」から、「とりあえず入れて後で整える」に発想が転換した
• ETL ― Extract, Transform, Load。データソースから抽出（Extract）→ 変換（Transform）→ DWHにロード（Load）の順で統合する伝統的な方式。専用ETLツール（Informatica・Talend・Pentaho）でジョブを組むスタイルで、オンプレ DWH 時代の主流。今もレガシーDB連携では現役
• Eval（LLM Eval） ― LLM 出力品質を定量・定性で評価する手法。プロンプト変更やモデル切替で出力が劣化しないかを CI に組み込んで自動検出するのが LLMOps の標準。BLEU・ROUGE・LLM-as-a-judge・人手レビューを組み合わせ、回帰検出と継続改善のサイクルを回す
• Eventual Consistency（結果整合性） ― 一時的にはデータの不整合を許容するが、十分な時間が経てば必ず整合する、という分散システムの一貫性モデル。NoSQL や CDN キャッシュで広く採用される現実解で、強一貫性に比べてスケールと可用性に優れる。「商品レビューの即時反映が数秒遅れてもよい」のような要件に向く

F

• FaaS ― Function as a Service。関数単位でコードをアップロードし、リクエスト発生時のみ実行されて従量課金されるクラウドサービス。AWS Lambda・Google Cloud Functions・Azure Functions が代表。サーバー管理が不要で、トラフィックが少ない API・イベント処理・バッチに向くが、コールドスタートと長時間実行の制約がある
• Feature Flag ― 機能のON/OFFをコードのデプロイなしに動的に切り替える仕組み。LaunchDarkly や Split.io などの専用サービスもあり、A/Bテスト・段階的ロールアウト・「特定顧客だけに先行公開」等を実現する。トランクベース開発（main 直接コミット）と相性が良く、未完成機能を本番マージしてもユーザーには見せない運用が可能
• FIDO2 / WebAuthn ― FIDO Alliance と W3C が策定した、フィッシング耐性のある公開鍵ベース認証規格。デバイス内に秘密鍵を保管し、サーバ側に公開鍵だけを登録する仕組みで、Passkey の技術基盤になっている。パスワード漏洩や中間者攻撃が原理的に成立しない
• FinOps ― Financial Operations。クラウドコストを「使い切ったら集計する」のではなく、運用業務として継続的に最適化する文化と実践。タグ付けによるコスト配賦、Reserved Instance/Savings Plan の活用、不要リソース棚卸し等を、エンジニア・財務・経営が協働で進める。FinOps Foundation が知識体系を整備中

G

• GDPR ― General Data Protection Regulation（EU一般データ保護規則）。EU 域内の個人データを取り扱う際の義務を定めた規則で、域外企業にも適用される（域外適用）。同意取得・データ持ち出し制限・忘れられる権利・侵害時の72時間以内通知などが要点で、違反時は最大で全世界年間売上の4%の制裁金。日本企業もEU向けサービスでは対応必須
• Grafana ― Grafana Labs 社の OSS ダッシュボードで、Prometheus・Loki・Tempo・CloudWatch・Datadog 等多数のデータソースに接続し、メトリクス・ログ・トレースを統合可視化する。アラート機能・テンプレート変数・ダッシュボード共有で監視運用の中核に座っており、SRE/DevOps 現場の事実上の標準
• GraphQL ― Facebook（Meta）発のクエリ言語ベースAPI規格で、クライアント側が必要なフィールドだけを1リクエストで指定して取得できる。REST の「過剰取得・不足取得」問題を解消する一方、N+1 クエリやキャッシュ設計の難しさが固有の課題。Apollo・Relay・Hasura・Hot Chocolate 等のエコシステムが充実
• gRPC ― Google 発の高性能 RPC プロトコルで、HTTP/2 上でバイナリ形式（Protobuf）を使って通信する。多言語対応の自動コード生成、ストリーミング、双方向通信に対応し、マイクロサービス間の内部通信で広く採用される。ブラウザからの直接呼び出しは grpc-web 経由となる

H

• Helm ― Kubernetes のアプリケーション定義（YAML群）をテンプレート化し、パッケージ（Chart）として配布・インストール・バージョン管理できるパッケージマネージャ。「Linuxにおける apt」の Kubernetes 版というイメージで、複雑な構成の標準パッケージを helm install 一発で展開できる。本番運用では値の上書きとロールバック機能が要となる
• HSTS ― HTTP Strict Transport Security。ブラウザに対し「以後このドメインは必ず HTTPS で接続せよ」と宣言する HTTP レスポンスヘッダ。一度受信するとキャッシュ期間中は HTTP アクセスがブラウザ側で自動 HTTPS 化され、中間者攻撃のリスクを下げる。ただし設定ミスで全アクセス不能になる怖さもあり、max-age を短くして段階導入するのが安全
• HTTP / HTTPS ― Hypertext Transfer Protocol。Web 通信の標準プロトコルで、HTTPS は TLS で暗号化された HTTP。HTTP/1.1 から HTTP/2（多重化）→ HTTP/3（QUIC ベース、UDP）へと進化し、それぞれパフォーマンス特性が異なる。現代では HTTPS が事実上の必須要件
• Hydration ― SSR で送られた静的 HTML に対し、ブラウザ側で JS を実行して「インタラクティブな状態」へ昇格させる処理。React・Vue・Svelte などの SSR フレームワークで使われ、JS の読み込み・実行が遅いと「見えるけど押せない」時間が発生する。これを軽減するために Partial Hydration・Islands Architecture・RSC 等の手法が登場した

I

• IaaS ― Infrastructure as a Service。仮想マシン・ストレージ・ネットワーク等のインフラリソースを API 経由で提供するクラウドサービス。AWS EC2、Google Compute Engine、Azure Virtual Machines が代表。OS から上は利用者責任となるため柔軟性は最大だが、運用負荷も大きい
• IaC ― Infrastructure as Code。インフラ構成をコード（宣言的または手続的）で定義し、Git で管理しレビュー・自動適用する手法。Terraform・AWS CloudFormation・Pulumi・Ansible 等が代表で、「手作業構築・誰も再現できない」状態から脱却する標準アプローチ。災害復旧・環境複製の精度が劇的に上がる
• IAM ― Identity and Access Management。組織内のID・権限を統合管理する仕組み全般。クラウドの文脈では AWS IAM・Azure RBAC・GCP IAM のように、誰が（プリンシパル）何に対して（リソース）どんな操作（アクション）を行えるかを定義する基盤を指す
• IDaaS ― Identity as a Service。認証・認可基盤を SaaS として提供するサービスで、Auth0・Okta・Microsoft Entra ID・Firebase Authentication が代表。SSO・MFA・ソーシャルログイン・SCIM プロビジョニング等を自社実装せずに利用でき、「自前で認証基盤を作るな」が現代の鉄則
• IDS / IPS ― Intrusion Detection / Prevention System。不正侵入の検知（IDS）または検知＋遮断（IPS）を行うネットワークセキュリティ装置。シグネチャベース・異常検知ベース等で動作し、近年は EDR/XDR と統合された SIEM 連携が主流。クラウドでは AWS GuardDuty・Azure Defender 等のマネージド型に置き換わりつつある
• IdP ― Identity Provider。認証を一元的に担う中央サービスで、SAML や OIDC 経由で各サービス（Service Provider）に認証結果を渡す。SSO の中核で、社内では Microsoft Entra ID・Google Workspace、コンシューマでは Google・Apple がよく使われる
• Idempotency（冪等性） ― 同じ操作を何度実行しても、結果が同じ状態に収まる性質。HTTP で言えば PUT・DELETE は冪等、POST は冪等でない。分散システムやネットワーク再送が前提となる現代では、API設計で冪等性キーを必須にするのが安全策で、Stripe APIの Idempotency-Key ヘッダが好例
• IPA ― 独立行政法人 情報処理推進機構。経済産業省所管の公的機関で、情報処理技術者試験の運営、非機能要求グレード・セキュア開発ガイド等の策定、脆弱性情報の収集（JVN）等を担う。日本のIT政策・標準化のハブ
• ISR ― Incremental Static Regeneration。Next.js 由来のレンダリング方式で、SSG で生成した静的HTMLを、リクエスト時または時間経過後にバックグラウンドで再生成する。「ビルド時に全ページ生成は重いが、ページ数が多い」用途で SSG と SSR のいいとこ取りを実現する

J

• JWT ― JSON Web Token。ヘッダ・ペイロード・署名の3パートを . で連結したトークン形式で、サーバ側にセッション情報を持たないステートレス認証で広く使われる。署名検証だけで真正性を確認できる反面、発行後に取り消せない（無効化が難しい）性質があり、有効期限を短く保ち refresh token と組み合わせるのが定石

K

• Kafka ― LinkedIn 発の高スループット分散メッセージング基盤。トピックに対する追記専用ログ構造で、毎秒数百万メッセージを安定処理できる。イベント駆動アーキテクチャ・ストリーミング処理・データ統合の中核として広く採用され、Confluent や AWS MSK などのマネージドサービスもある
• Kubernetes / K8s ― コンテナを大規模に動かすためのオーケストレーションプラットフォーム（Google が Borg を元に OSS 化）。配置・スケール・自己回復・サービス発見等を自動化し、宣言的構成（YAML）で全てを管理する。CNCF の Graduated プロジェクトで、クラウドネイティブの事実上の標準
• KVS ― Key-Value Store。キーから値を高速に取り出すことに特化した NoSQL の基本形。Redis・Memcached・Amazon DynamoDB・etcd 等が代表で、キャッシュ・セッション管理・リアルタイム集計・分散ロックなど用途は広い。複雑なクエリは苦手なため RDB と併用するのが普通

L

• LLM ― Large Language Model（大規模言語モデル）。膨大なテキストで訓練されたニューラルネットワークで、Claude・GPT・Gemini・Llama 等が代表。チャット応答・要約・コード生成・関数呼び出し等の汎用的な自然言語処理を実現する基盤技術で、生成AI時代のアーキテクチャの中心
• LLMOps ― LLM を運用するためのプロセス・ツール群。プロンプト管理・バージョニング・評価（Eval）・モニタリング・コスト管理・プロンプトインジェクション対策等を含む。MLOps の発展形で、LangSmith・Helicone・PromptLayer などのツールが台頭中
• LCP / INP / CLS ― Google が定める Core Web Vitals の3指標。LCP（Largest Contentful Paint）は最大要素の表示時間、INP（Interaction to Next Paint）はユーザー操作への応答性（FID の後継）、CLS（Cumulative Layout Shift）はレイアウト安定性。SEO ランキング要素にも組み込まれており、フロントエンド最適化の評価軸

M

• MDM ― Master Data Management。顧客・商品・組織等、複数システムに分散したマスタデータを統合管理する手法または製品。重複排除・名寄せ・統一IDの付与で全社のデータ品質を底上げし、BI 分析や業務効率の前提を整える。Informatica MDM・Reltio・SAP MDG が代表
• MFA ― Multi-Factor Authentication（多要素認証）。「知識（パスワード）」「所持（スマホ・トークン）」「生体（指紋・顔）」のうち2要素以上を組み合わせる認証方式。SMS・TOTPアプリ・WebAuthn 等の手段があり、SMS は SIM スワップ攻撃に弱いため WebAuthn 系が推奨
• mTLS ― Mutual TLS（相互TLS認証）。クライアントとサーバーが互いに証明書を提示して相手を認証する通信方式で、片方向の TLS（サーバー証明書のみ）の上位概念。サービスメッシュ（Istio・Linkerd）やゼロトラストの内部通信で広く使われ、「ネットワーク内部だから安全」を前提にしない設計を可能にする
• MTBF / MTTR ― Mean Time Between Failures（平均故障間隔）と Mean Time To Repair / Recovery（平均修復時間）。前者は「次の障害までどれくらい持つか」、後者は「壊れてからどれくらいで戻るか」を表す信頼性指標。可用性 ≒ MTBF / (MTBF + MTTR) という関係で、SLA設計の基本式
• MVC / MVVM ― UI と業務ロジックを分離する古典的パターン。MVC（Model-View-Controller）は Web フレームワーク全般、MVVM（Model-View-ViewModel）は WPF・SwiftUI・Vue 等のデータバインディング系で採用されてきた。現代の React・SPA では Flux/Redux 系の単方向データフローに置き換わりつつある

N

• NIST ― National Institute of Standards and Technology（米国国立標準技術研究所）。SP 800 シリーズなどでセキュリティ標準を策定し、特に NIST SP 800-207（ゼロトラスト）、SP 800-53（管理策）、Cybersecurity Framework は世界的に参照される。「迷ったら NIST」と言われる業界バイブル
• NoSQL ― 非リレーショナル型 DB の総称で、KVS・ドキュメント（MongoDB）・ワイドカラム（Cassandra）・グラフ（Neo4j）の4系統が代表。RDB が苦手な大規模水平スケールや柔軟スキーマに強い反面、トランザクション・JOIN は弱い。用途に合わせて RDB と使い分けるのが現実解
• NFR（Non-Functional Requirements） ― 非機能要件。性能・可用性・スケーラビリティ・セキュリティ・運用性・保守性など、機能以外の「どう動くべきか」の要件群。IPA の「非機能要求グレード」が代表的なフレームで、要件定義段階で合意することが品質安定の鍵
• NAT ― Network Address Translation。プライベートIPアドレス（社内・LAN）と公開IPアドレスを変換する仕組みで、家庭ルータからクラウドの NAT Gateway まで広く使われる。IPv4 アドレス枯渇への対策として普及し、内部ホストの隠蔽効果もある

O

• OAuth 2.0 ― 認可のためのプロトコルで、ユーザーに代わってサードパーティアプリにリソースアクセスを許可する仕組み（「Googleアカウントで連携」等の裏側）。トークンの種類（アクセストークン・リフレッシュトークン）とフロー（Authorization Code・PKCE 等）を理解するのが要点。「認証ではない」ことが最重要ポイント
• OIDC ― OpenID Connect。OAuth 2.0 の上に「認証」機能を載せた拡張プロトコルで、ID トークン（JWT）を使ってユーザーの本人確認情報を提供する。「OAuth は認可、OIDC は認証」と覚えると整理しやすく、現代のソーシャルログインや SSO の標準
• OLAP / OLTP ― DB 用途の2大分類。OLTP（Online Transaction Processing）は業務系で、注文・在庫等の「短時間で多数の小さな更新」を扱う（PostgreSQL・MySQL）。OLAP（Online Analytical Processing）は分析系で、「大量データの集計クエリ」を扱う（BigQuery・Snowflake・Redshift）。それぞれ最適化の方向が真逆
• One-way Door ― Amazon の Jeff Bezos が広めた意思決定の分類用語で、「一度通ったら戻れないドア」を意味する。データベース選定・公開API設計・データモデルなどの不可逆な判断は One-way Door として慎重に進め、可逆な判断（Two-way Door）は素早く試す、という使い分けが推奨される
• OpenTelemetry ― CNCF プロジェクトで、メトリクス・ログ・トレースの収集・送信を標準化したベンダー中立の仕様と SDK。OTel と略され、計装コードを書き換えずにバックエンド（Datadog・Honeycomb・Grafana 等）を切り替えられるのが利点。観測性ツール選定のロックイン回避に有効
• Outbox パターン ― DB 書き込みとメッセージ送信を1つのトランザクションで整合させる設計パターン。同一DBにイベント記録用テーブル（Outbox）を持ち、まず DB トランザクションで業務更新と Outbox 書き込みを同時実行、別プロセスが Outbox を読んでメッセージ送信する。分散トランザクションを避ける現実解
• OWASP ― Open Web Application Security Project。Web セキュリティに関する OSS コミュニティで、「OWASP Top 10」（最重要脆弱性ランキング）が世界的バイブル。ZAP（脆弱性スキャナ）、ASVS（検証標準）、SAMM（成熟度モデル）など、無償の良質なリソースが豊富

P

• P95 / P99 ― 応答時間を 95 / 99 パーセンタイルで測る指標。「95% / 99% のリクエストはこの時間以内に返せた」という意味で、平均値では隠れる「遅い少数」のユーザー体験を捉えられる。SLO 定義や性能ベンチマークでは平均より P95/P99 を見るのが現代の標準
• PaaS ― Platform as a Service。アプリの実行環境（OS・ミドルウェア・スケーリング基盤）まで抱合してクラウド事業者が提供する形態。Heroku・Google App Engine・Azure App Service・Render・Vercel が代表で、デプロイ手間が最小な反面、内部の細かい制御はできない
• Passkey ― FIDO2/WebAuthn を基盤としたパスワードレス認証の総称。生体認証や PIN でデバイス内秘密鍵を解錠し、サーバとは公開鍵暗号で認証するためフィッシング耐性が原理的に高い。Apple・Google・Microsoft が2022年から推進し、2024年以降コンシューマWebでも普及が加速
• PCI DSS ― Payment Card Industry Data Security Standard。クレジットカード会員データを扱う事業者が遵守すべき国際セキュリティ基準。ネットワーク分離・暗号化・ログ管理・脆弱性スキャン等12要件があり、決済を取り扱うEC・SaaSは必須対応。違反時は罰金・カードブランドからの取引停止リスクがある
• PII ― Personally Identifiable Information（個人識別情報）。氏名・住所・電話番号・メールアドレス・マイナンバー等、個人を特定できる情報の総称。GDPR・改正個人情報保護法での取扱い対象で、ログ・分析データに混入させない設計、暗号化保管、アクセス監査が基本要件
• PKI ― Public Key Infrastructure（公開鍵基盤）。デジタル証明書を発行・検証する CA（認証局）を頂点とした信頼の仕組みで、HTTPS の TLS 証明書、コード署名、メール暗号化（S/MIME）の根幹。ルートCA から中間CA を経て末端証明書に署名するチェーン構造になっている
• PoC ― Proof of Concept（概念実証）。「本格開発に進んでよいか」を判断するための小さな検証で、技術的実現性・性能・コストの妥当性を短期間で確認する。生成AI領域で特に頻出する用語で、PoC 段階で評価指標と中止条件を決めておくのが鉄則
• Postmortem（ポストモーテム） ― 障害・インシデント後の振り返りドキュメント。発生事象・影響範囲・タイムライン・根本原因・再発防止策を記録し、組織全体で共有する。個人の責任追及ではなく仕組みの改善が目的（Blameless Postmortem）で、SRE 文化の中核
• Prometheus ― CNCF の OSS 時系列メトリクス監視システムで、Pull 型の収集・PromQL クエリ言語・アラートマネージャ・サービスディスカバリを統合する。Kubernetes 環境のデファクトで、Grafana と組み合わせて使われるのが定番。長期保存は Thanos・Cortex・Mimir 等で拡張する
• Pub/Sub ― Publisher-Subscriber。発信者（Publisher）が特定の購読者を意識せずトピックにメッセージを発信し、購読者（Subscriber）が興味あるトピックを購読する非同期メッセージングパターン。送受信を疎結合にできるのが利点で、Kafka・Google Pub/Sub・AWS SNS・Redis Pub/Sub 等が代表

Q

• QPS ― Queries Per Second。1秒あたりのクエリ（リクエスト）数で、性能設計・キャパシティプランニングの基本単位。「ピーク時に何QPS耐える必要があるか」から逆算してインフラ規模を決める。RPS（Requests Per Second）と同義で使われることも多い
• QUIC ― Quick UDP Internet Connections。Google 発の UDP ベースの新トランスポートプロトコルで、TCP+TLS の機能を統合し、コネクション確立を高速化（0-RTT）し、パケットロス時の影響を局所化した。HTTP/3 の基盤で、モバイル環境のパフォーマンスを大きく改善する

R

• RBAC ― Role-Based Access Control。役割（ロール）にパーミッションを紐づけ、ユーザーをロールに割り当てて認可する最も普及したモデル。「管理者ロール」「閲覧者ロール」のように整理でき、運用負荷が低い反面、細かい例外条件には弱い。多くの場合 RBAC をベースに ABAC や ReBAC を補強的に使う
• RDB（リレーショナルデータベース） ― 行と列の表構造で正規化されたデータを管理し、ACIDトランザクションと SQL を提供する古典的 DB。PostgreSQL・MySQL・Oracle・SQL Server が代表。迷ったらこれと言える堅実な選択肢で、現代でも 9 割以上の業務システムの中核
• ReBAC ― Relationship-Based Access Control。リソース間の関係（所有者・メンバー・親子等）に基づいて認可するモデル。Google の Zanzibar 論文を元に SpiceDB や OpenFGA 等の OSS が登場し、SaaS の細粒度権限（「このフォルダのメンバーは中のファイル全部見られる」等）を扱いやすくする
• RED ― Rate（リクエスト数）・Errors（エラー数）・Duration（応答時間）。サービス監視のメトリクス設計フレームで、リクエストを処理するシステム（Web API 等）の健全性把握に向く。USE メソッドが基盤側、RED がサービス側の補完関係
• REST ― Representational State Transfer。HTTP メソッド（GET/POST/PUT/DELETE 等）とリソース URL を組み合わせて API を設計するスタイル。Roy Fielding の博士論文が起点で、シンプルさとブラウザ親和性から公開APIの事実上の標準となった。HATEOAS 等の純粋な定義より、緩い RESTish が現実
• ROI ― Return on Investment（投資対効果）。投資額に対してどれだけのリターン（売上増・コスト削減）を生んだかの比率で、IT 投資判断の最重要指標の1つ。アーキテクチャ選定でも「技術的に正しい」だけでなく ROI で語れる必要がある
• RPO / RTO ― Recovery Point Objective（許容データ損失時間）と Recovery Time Objective（許容停止時間）。前者は「最後のバックアップからどれだけ前まで戻ってよいか」、後者は「障害発生から何分以内に復旧すべきか」を表し、BCP・DR 設計の基本2指標。業務影響度に応じて段階定義する
• RSC ― React Server Components。サーバ側で実行され HTML を生成する React コンポーネントで、Next.js App Router で標準採用された。クライアント JS バンドルを削減でき、DB アクセスをコンポーネント内で直接書ける反面、設計思想が従来の React と大きく異なる
• Runbook ― 障害対応の手順書で、「アラート発火時に誰が・どの順番で・どのコマンドを実行するか」を定型化したドキュメント。Postmortem の改善項目として整備されることが多く、深夜のオンコールでも判断ミスなく対応できる状態を目指す。近年は自動実行可能な Automated Runbook が主流に

S

• SaaS ― Software as a Service。ブラウザだけで使える即時利用型のクラウドサービスで、Slack・Salesforce・Microsoft 365・Google Workspace 等が代表。インストール・運用が不要で、ライセンスもサブスクリプション型。エンタープライズIT支出の最大カテゴリに成長した
• Saga パターン ― マイクロサービスを跨る業務処理を、各サービスのローカルトランザクションと補償処理（取り消し処理）の連鎖で整合させる設計パターン。分散トランザクション（2PC）を避けつつ最終的な整合性を実現する。Choreography 型と Orchestration 型の2種類があり、後者は Camunda 等の専用基盤が活躍
• SAML ― Security Assertion Markup Language。XML ベースのエンタープライズ SSO プロトコルで、OIDC 登場以前から長く使われてきた古参。重厚な仕様だが企業領域では今も現役で、Salesforce・ServiceNow 等のエンタープライズ SaaS では標準対応している
• SAST / DAST ― Static/Dynamic Application Security Testing。SAST はソースコード静的解析で脆弱性を検出（SonarQube・Snyk Code・Semgrep）、DAST は実行中アプリへ攻撃を試みて検出（OWASP ZAP・Burp）する。互いに補完関係にあり、CI に両方組み込む DevSecOps が現代の標準
• SBOM ― Software Bill of Materials（ソフトウェア部品表）。アプリが依存する全ライブラリ・コンポーネントの一覧で、SPDX や CycloneDX が代表フォーマット。サプライチェーン攻撃（Log4Shell 等）への対策として米国大統領令で連邦調達では必須化され、世界的に普及が進む
• Schema Registry ― Avro・Protobuf・JSON Schema 等のスキーマ定義を中央で管理する仕組み。Confluent Schema Registry が代表で、Kafka エコシステムでデータ送受信間の互換性を保つために必須。スキーマ変更時の互換性チェック（前方・後方・完全互換）が組み込まれる
• SLA / SLO / SLI ― Service Level Agreement（顧客との外部契約）／Objective（社内目標）／Indicator（測定指標）。SLI で実測し、SLO で目標を設定し、SLA で対外コミットメントを結ぶ階層関係。SLO < SLA とすることで、SLO 違反時点で内部対応を始める運用が可能になる
• SLSA ― Supply-chain Levels for Software Artifacts。Google 発でOpenSSF が標準化を進める、ソフトウェアサプライチェーンのセキュリティ成熟度フレーム。Level 1〜4 で「ビルドプロセスの来歴と完全性をどこまで保証できるか」を段階評価し、SBOM と並ぶサプライチェーン対策の柱
• SOAP ― Simple Object Access Protocol。XML ベースの RPC プロトコルで、WS-Security・WS-* 規格群と組み合わせる重厚な仕様。1990年代後半〜2000年代の Web サービス標準だったが、REST と GraphQL に置き換わり、現在はレガシー連携や金融・公共系で残存
• SOC 2 ― Service Organization Control 2。AICPA が定めるサービス提供事業者の内部統制監査フレームワークで、セキュリティ・可用性・処理の完全性・機密性・プライバシーの5原則を評価する。B2B SaaS が大企業顧客と契約する際にほぼ必須の監査レポートで、Type 1 と Type 2 の2種類がある
• SOLID 原則 ― オブジェクト指向設計の5原則で、Single Responsibility（単一責任）、Open/Closed（開放閉鎖）、Liskov Substitution（リスコフ置換）、Interface Segregation（インタフェース分離）、Dependency Inversion（依存性逆転）の頭字語。Robert C. Martin が体系化し、保守性・拡張性の高いコード設計の基本指針として定着
• SPA ― Single Page Application。1つのHTMLを最初に読み込んだ後、画面遷移を JS で描画し直すアプリ形態。React・Vue・Angular で構築するのが一般的で、ネイティブアプリに近いUX を Web で実現できる。SEO・初回表示遅延の課題に対しては SSR・SSG との併用で解決
• SPOF ― Single Point of Failure（単一障害点）。冗長化されておらず、そこが落ちるとシステム全体が止まる構成要素。アーキテクチャレビューで真っ先にチェックすべき項目で、データベースのプライマリ単一構成・LB の片寄せ・特定リージョン依存などが典型例
• SQL インジェクション ― 入力値に SQL 文を混入させ、DB を不正操作する古典的攻撃。プレースホルダ（パラメータ化クエリ）を使えば原理的に防げるが、文字列連結で SQL を組み立てる古いコードでは今も多発。OWASP Top 10 の常連
• SRE ― Site Reliability Engineering。Google で生まれた信頼性エンジニアリングの方法論で、「ソフトウェアエンジニアリングで運用問題を解く」のが思想。SLO・エラーバジェット・Toil 削減・Postmortem 等の概念をパッケージ化し、開発と運用の対立を解消する枠組みを提供する
• SSG ― Static Site Generation。ビルド時に全ページの静的 HTML を生成し、CDN で配信する方式。Astro・Next.js・Hugo・Jekyll 等が代表で、表示速度・セキュリティ・低運用コストに優れる。本ブログ自体も Astro SSG で構築されている
• SSO ― Single Sign-On。1度の認証で連携した複数サービスにログインできる仕組みで、SAML や OIDC で実装される。社内では Microsoft Entra ID や Okta、コンシューマでは Google・Apple アカウントが代表的な IdP。「パスワードを覚える数を減らす」だけでなくセキュリティ集約効果も大きい
• SSR ― Server Side Rendering。サーバ側で HTML を組み立ててブラウザに返す方式。CSR と比較して初回表示・SEO・低スペック端末に強く、Next.js・Nuxt・SvelteKit などのフレームワークが対応する。サーバ負荷とデプロイ複雑性が増すトレードオフがある
• SSRF ― Server-Side Request Forgery。サーバ側に内部ネットワークへのリクエストを送らせる攻撃で、クラウドのメタデータエンドポイント（169.254.169.254）への到達で AWS の認証情報を盗まれた Capital One 事件（2019年）が著名な被害例。IMDSv2 への移行と URL 入力のバリデーションが対策

T

• Terraform ― HashiCorp の IaC ツールで、HCL（独自言語）でクラウド資源を宣言的に定義し、terraform apply で実際の状態と差分を取って適用する。AWS・Azure・GCP・Datadog 等多数のプロバイダに対応し、マルチクラウド・SaaS 設定管理の事実上の標準。BSL ライセンス変更を契機に OSS フォーク OpenTofu が分岐
• TLS ― Transport Layer Security。通信を暗号化・認証する標準プロトコルで、HTTPS の中身（SSL の後継）。現在は TLS 1.3 が主流で、TLS 1.0/1.1 は脆弱性のため非推奨。Let’s Encrypt の登場で誰でも無償で証明書を取得できるようになり、Web の HTTPS 化が一気に進んだ
• TOGAF ― The Open Group Architecture Framework。EA の業界標準フレームワークで、ADM（Architecture Development Method）と呼ばれる8フェーズの進め方が中核。資料体系が膨大で大企業向けだが、考え方は中規模プロジェクトでも参考になる。認定資格も普及している
• Toil ― SRE 用語で、「自動化できるはずなのに手作業で繰り返している運用作業」を指す。手作業のデプロイ・アラート対応・ユーザーアカウント発行などが典型で、Toil 比率を 50% 以下に抑えることが SRE チームの KPI とされる。継続的な自動化投資の根拠付けに使われる
• TOTP ― Time-based One-Time Password。30秒ごとに変わる6桁ワンタイムパスワードを共有秘密鍵から計算する方式（RFC 6238）。Google Authenticator・Authy・1Password 等のアプリで広く使われ、SMS よりセキュリティが高い MFA の手段として標準的
• tRPC ― TypeScript で型を共有する RPC スタイルのAPI規格で、サーバとクライアントが同じ TS リポジトリにある場合に強い。GraphQL や OpenAPI のようなスキーマ定義なしに、TypeScript の型推論だけで API の型安全性を実現する。モノレポ構成の Next.js プロジェクト等で人気急上昇

U

• USE ― Utilization（利用率）・Saturation（飽和度）・Errors（エラー数）。Brendan Gregg が提唱した、リソース（CPU・メモリ・ディスク・ネットワーク）監視のメトリクス設計フレーム。「リソースが詰まっていないか」を体系的に見るための補助線で、サービス側の RED と組み合わせて使う

V

• VPC ― Virtual Private Cloud。クラウド上に構築する論理的に隔離された仮想ネットワークで、AWS VPC・Azure VNet・GCP VPC が代表。サブネット分割・ルーティング・セキュリティグループ・NAT Gateway 等を組み合わせ、クラウド上に擬似的な社内ネットワークを構築する基本単位
• VPN ― Virtual Private Network。公衆インターネット上に暗号化トンネルを張って、専用線相当のセキュアな通信を実現する技術。在宅勤務時の社内ネットワーク接続や、オンプレ-クラウド間の Site-to-Site 接続で使われる。ゼロトラスト化の進展で、企業VPN の必要性自体が再考されている

W

• WAF ― Web Application Firewall。OSI 7層の HTTP リクエスト/レスポンスを検査し、SQL インジェクション・XSS・パストラバーサル等の Web 攻撃を遮断する防御層。AWS WAF・Cloudflare・Akamai・Imperva が代表で、CDN と統合された形態が多い。アプリ側の対策と多層防御を構成する
• WCAG ― Web Content Accessibility Guidelines。W3C が策定する Web アクセシビリティの国際基準で、A・AA・AAA の3レベルがある。多くの国・自治体が WCAG 2.1 AA 準拠を法的要件としており、公共系・大企業サイトでは必須対応。OWASP の Top 10 と並ぶ Web 開発者の必修知識
• WebAuthn ― FIDO2 の W3C 標準 API で、ブラウザから公開鍵ベース認証を扱うための JavaScript インターフェース。Passkey 実装の中核技術で、Chrome・Safari・Firefox・Edge 全てが対応。生体認証・セキュリティキー・プラットフォーム認証器を統一的に扱える
• WebSocket ― HTTP 接続を双方向通信にアップグレードするプロトコル（RFC 6455）。サーバから能動的にプッシュできるため、チャット・リアルタイム通知・オンラインゲーム・株価ティッカー等で広く使われる。最近は Server-Sent Events（SSE）や WebTransport との使い分けも論点

X

• XSS ― Cross-Site Scripting。悪意あるスクリプトを他ユーザーのブラウザで実行させ、Cookie・トークン・操作を奪う攻撃。ユーザー入力の出力エスケープ漏れが原因で、Stored・Reflected・DOM Based の3種類がある。React 等のモダンフレームワークは標準でエスケープするが、dangerouslySetInnerHTML 等で容易に穴が開く

Z

• Zero Trust（ゼロトラスト） ― 「暗黙の信頼をしない」を原則とする現代のセキュリティモデル。ネットワーク内部だから安全という前提を捨て、全ての通信・アクセスを毎回認証・認可・暗号化する。NIST SP 800-207 が標準を策定し、リモートワーク普及で一気に主流化した

日本語（五十音順）

あ行

• アーキテクト ― システム全体の構造と主要な技術判断に責任を持つ役割で、要件と制約のバランスを取りつつ長期的な保守性を含む設計を導く。ソフトウェア・データ・セキュリティ・エンタープライズ等の領域別アーキテクトに細分化されることもある。コードを書く現場との距離感が職位や組織で大きく異なる
• アクセシビリティ ― A11y を参照
• 暗号化 ― データを鍵で保護し、第三者が読めないようにする技術。「保管時の暗号化」（DBや S3 のデータ at rest）と「通信時の暗号化」（TLS 等）の両方が必要で、鍵管理（KMS・HSM）も含めて設計する。共通鍵（AES）と公開鍵（RSA・ECDSA）の使い分けが基本
• イベント駆動 ― EDA を参照
• エラーバジェット ― SLO で許容される「失敗の残量」SRE の中核概念。例えば SLO 99.9% なら月間で約43分の停止が許容範囲となり、これを使い切ったら新機能リリースを止めて信頼性改善に注力する、というルールベースの判断を可能にする
• オブザーバビリティ（可観測性） ― システム内部の状態を、出力（メトリクス・ログ・トレース）から推測できる性質。「事前に予想できなかった問題でも後から原因を辿れる」ことを目指す設計思想で、従来のモニタリング（既知の問題を監視）の上位概念。OpenTelemetry や Datadog・Honeycomb・Grafana 等のツール群が前提

か行

• 可用性 ― 障害なくサービスが使える時間の割合で、99.9%（年8.76時間停止）、99.99%（年52分停止）、99.999%（年5分停止）等の数値で表す。一般的に「9」の数を増やすほど指数的にコストが増えるため、業務影響度に応じて妥当な水準を選ぶのが要点
• カオスエンジニアリング ― 本番環境で意図的に障害を注入し、システムが想定通りに耐えられるかを検証する手法。Netflix の Chaos Monkey が起点で、「障害は必ず起きるなら、計画的に起こして耐性を確かめよう」という発想。Chaos Mesh・LitmusChaos・AWS FIS 等のツールがある
• カナリアリリース ― 新バージョンを一部のユーザー（例：5%）に先行公開し、エラー率や指標を監視してから残りに展開するデプロイ手法。問題があれば被害を限定でき、Blue/Green より細かいコントロールが可能。Argo Rollouts や Flagger 等の専用ツールがある
• 結果整合性 ― Eventual Consistency を参照
• 構造化ログ ― 単なるテキストではなく、JSON 等の機械可読フォーマットで出力し、フィールド単位で検索・集計できるログ。Elasticsearch や Loki・Datadog Logs 等の現代ログ基盤の前提で、level・trace_id・user_id 等の標準フィールド設計が運用効率を左右する
• コンテナ ― ホスト OS のカーネルを共有しつつ、ファイルシステム・プロセス・ネットワークを隔離した軽量な実行環境。VM より起動が速く、リソース消費も少ない。Docker が代表ツールで、Kubernetes が大規模運用の標準。クラウドネイティブの基礎単位
• コンウェイの法則 ― Conway の法則を参照

さ行

• サーバーレス ― サーバーのプロビジョニング・運用を意識せずアプリを動かせる実行モデルで、FaaS（Lambda 等）に加えて、Cloud Run・Fargate・DynamoDB のような「インスタンスを意識しない」マネージドサービス全般を含む。アイドル時のコストがゼロに近く、スケール上限も実用上ほぼ無限
• サービスメッシュ ― マイクロサービス間通信をサイドカープロキシ（Envoy 等）経由にし、認証・暗号化・トラフィック制御・観測性を一元管理する仕組み。Istio・Linkerd・Consul Connect が代表で、アプリコードに手を入れずにゼロトラスト・カナリア・タイムアウト等を後付けできる
• シークレット管理 ― API キー・パスワード・証明書等の機密情報を安全に保管・配布・ローテーションする仕組み。AWS Secrets Manager・HashiCorp Vault・Kubernetes Secrets 等が代表。コードや環境変数への直書きは禁止で、暗号化保管とアクセス監査が前提
• スケーラビリティ（拡張性） ― 負荷の増加に対しリソースを増やして対応できる性質で、サーバを増やす「水平（スケールアウト）」と、サーバを大きくする「垂直（スケールアップ）」の2方向がある。ステートレス設計が水平スケールの前提条件で、現代では水平スケールが主流
• ステージング環境 ― 本番とほぼ同構成で最終検証を行う環境。「本番（Production）／ステージング（Staging）／開発（Development）」の3層が基本で、ステージングでは本番相当データのマスキング版や合成データを使う。本番デプロイ前の最後の安全網として重要
• 冗長化 ― 同じ機能や構成要素を複数配置し、片方が故障しても全体が止まらないようにする設計。アクティブ-アクティブ（両方処理）とアクティブ-スタンバイ（片方待機）の方式があり、コスト・複雑性・切り替え時間でトレードオフ。可用性向上の基本テクニック

た行

• 多要素認証 ― MFA を参照
• データ基盤 ― 分析用データを集約・加工・配布するデータプラットフォーム全体構造。データレイク・DWH・ETL/ELT・データカタログ・BI ツール等の組合せで構成され、データドリブン経営や AI 活用の前提となる。Modern Data Stack（dbt・Snowflake・Fivetran 等）が現代の代表構成
• データカタログ ― 組織内に存在するデータセットのメタ情報（場所・スキーマ・所有者・利用例）を検索可能に整理する仕組み。DataHub・Atlan・Collibra・OpenMetadata 等が代表で、データガバナンス・データ民主化の基盤
• データレイク ― 構造化・半構造化・非構造化データを生の状態で大規模に蓄積するストレージ。Amazon S3・Google Cloud Storage・Azure Data Lake Storage が代表基盤で、Parquet・ORC・Iceberg・Delta Lake 等のフォーマットでクエリ可能にする
• デグレ（デグレード） ― 以前動いていた機能が、別の修正によって壊れてしまうこと。リグレッション（回帰）バグとも呼ばれ、これを防ぐために回帰テスト（リグレッションテスト）を CI で自動化するのが標準。古い機能ほど忘れられやすく、テストカバレッジの重要性が高い
• トイル ― Toil を参照
• ドメイン駆動設計 ― DDD を参照

な行

• 認可 ― AuthZ を参照
• 認証 ― AuthN を参照

は行

• パスワードレス認証 ― パスワードを使わず、生体・デバイス・公開鍵暗号で認証する方式。Passkey が代表的な実装で、フィッシング・パスワードリスト攻撃・SIMスワップ等の伝統的脅威を原理的に無効化する。2024年以降コンシューマでも普及加速中
• 非機能要件 ― 性能・可用性・セキュリティ・拡張性・運用性・保守性等、機能以外の「どう動くべきか」に関する要件群。IPA の「非機能要求グレード」が代表的なフレームワークで、要件定義段階で明文化・合意することが、後工程での認識ズレを防ぐ
• ブルーグリーンデプロイ ― Blue/Green デプロイを参照
• 分散トランザクション ― 複数のDB・複数のサービスに跨る更新を、全成功か全失敗のいずれかに揃える整合性保証。2 Phase Commit（2PC）等の古典手法は性能・可用性に大きな制約があり、マイクロサービス時代では可能な限り避けるのが定石。代わりに Saga パターンや Outbox パターンで結果整合性を取る
• ベクトルDB ― 数値ベクトル（埋め込み）の類似検索に特化した DB で、生成AI 時代に急成長。pgvector（PostgreSQL拡張）・Pinecone・Weaviate・Qdrant・Chroma が代表で、RAG（Retrieval-Augmented Generation）の検索層を担う
• ポストモーテム ― Postmortem を参照

ま行

• マイクロサービス ― 機能ごとに独立したアプリをネットワーク越しに連携させる構造で、各サービスは独立にデプロイ・スケールできる。組織のスケール（多数のチームが並行開発）に強い反面、運用複雑性・分散トランザクション・ネットワーク障害の難易度が大きく上がる。「組織にコンウェイの法則」が当てはまる代表例
• モジュラーモノリス ― 1つのアプリケーションとしてデプロイされるが、内部を複数モジュールに厳密に区切り、モジュール間は明確なインタフェースだけで通信する構造。2020年代に再評価され、マイクロサービスの複雑性を避けつつ将来分割の余地を残せる現実解として支持を集める
• モノリス ― 全機能を1つのアプリ・1つのデータベースで構成する伝統的な構造。シンプルでデバッグしやすく、トランザクション・整合性が容易な反面、規模拡大とチーム並行開発に弱い。「悪の代名詞」のように扱われた時期もあったが、近年は適材適所で再評価されている

や行

• 要件定義 ― システムが「何をすべきか」を業務側と合意するフェーズで、機能要件と非機能要件で構成される。スコープ・優先度・受入基準を明文化し、後工程の設計・実装・テストの拠り所となる。ここでの曖昧さがプロジェクト失敗の最大要因の1つ

ら行

• 列指向DB ― データを列ごとに連続して格納する DB で、特定列の集計クエリを大幅に高速化できる。BigQuery・Snowflake・Redshift・ClickHouse・Databricks Photon 等の分析系で標準採用。RDB（行指向）が業務系に強いのに対し、列指向は OLAP に強い

用語集の使い方

本用語集は、シリーズ全体で「この用語が分からない」と感じたときの索引として使うことを想定しています。

ITアーキテクチャの世界は略語が非常に多く、SaaS・PaaS・IaaS・FaaS のように似た略語が並ぶ領域や、認証・認可周りで AuthN / AuthZ / OAuth / OIDC / SAML が登場する領域は、用語の整理だけで一仕事になります。

本記事を一度通読しておくと、各個別記事を読むときに「これは前に見た略語だ」という認識が働き、読み進めるスピードが大きく上がります。完全に覚える必要はなく、こんな用語があるという肌感覚を掴むだけで十分です。

まとめ

本記事はシリーズ『生成AI時代のアーキテクチャ超入門』に出てくる専門用語の一覧リファレンスを整理しました。如何だったでしょうか。

各記事内にも初出用語には1行の解説を添えていますので、まずは個別記事を読み進め、用語が気になったときに本記事に戻る使い方が想定されています。

この用語集は記事の追加・更新に合わせて育てていく予定のドキュメントです。シリーズが進むにつれて項目を追加していきます。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。