用語集
AWS・Azure・GitHub・Google Cloud・LPI・IPA など各 IT 資格の重要用語 3,500 以上を、やさしい定義つきでまとめています。 上の検索・絞り込みで資格別に表示でき、資格を選ぶと各用語に「関連・前提の用語」も並びます。ログインすると、あなたの理解度 (解答履歴・復習・単語帳から自動判定)がバッジで表示され、クリックで手動更新できます。参考書の色つき重要語はホバー/クリックで 意味を表示。単語帳(Anki/Quizlet)への書き出しや、用語のつながりを見るナレッジマップにも対応しています。参考書へ戻る
資格で絞り込む3788 語
- 2 段階認証プロセス(2SV)
- パスワードに加えて二つ目の要素を求める認証強化。OU/グループ単位で強制でき、方式は SMS/プロンプト/最も強いセキュリティキー・パスキー(FIDO)まで幅がある。
- 2の補数
- コンピュータが負の数を表現する方式の一つ。ある数の2の補数は、全ビットを反転(1の補数)して1を加えることで得られる。加減算を同じ回路で扱えるため、多くのCPUで採用されている。
- 2進数
- 0と1の2つの数字だけで数を表す方法。コンピュータ内部では電気信号のオン・オフに対応させて情報を扱うため、2進数が基本となる。10進数との相互変換が基礎として問われる。
- 2相コミット(2PC)
- 複数のデータベースにまたがる分散トランザクションを一括で確定させるプロトコル。コーディネータが全参加者に準備(コミット可否)を問う準備フェーズと、全員一致で確定を指示するコミットフェーズの2段階からなる。参加者の途中障害に弱く、コーディネータ障害時はブロッキングが起こりうる。
- 2相ロック
- 分散/並行トランザクションの直列化可能性を保証するロック方式。トランザクションはロックを獲得するだけの成長相(growing phase)と、獲得済みロックを解放するだけの縮退相(shrinking phase)の2段階から成り、一度でもロックを解放したら新たなロックは獲得できない。この規律により、スケジュールが直列実行と等価であることが保証される。
- 3つの基本戦略(コストリーダーシップ/差別化/集中)
- マイケル・ポーターが提唱した競争優位の獲得パターンで、業界全体を対象に最低コストを追求するコストリーダーシップ戦略、独自の価値で差異化を図る差別化戦略、特定のセグメントに経営資源を集中する集中戦略(コスト集中/差別化集中)に大別される。ストラテジストは自社の経営資源・市場規模を踏まえ、いずれか一つを明確に選択すべきとされ、複数を中途半端に狙うと優位を失う「スタック・イン・ザ・ミドル」に陥る。
- 3層スキーマ(ANSI/SPARC)
- データベースを外部スキーマ(利用者ごとの見え方)・概念スキーマ(全体の論理構造)・内部スキーマ(物理的な格納方法)の3層に分けるアーキテクチャ。層を独立させることで、片方を変更してももう一方への影響を抑えられる。
- 3値論理(NULLの扱い)
- SQL の比較演算は TRUE・FALSE に加えて「不明(UNKNOWN)」を取りうる3値論理で動く。NULL を含む比較は原則 UNKNOWN になり、WHERE 句では UNKNOWN の行が除外されるため、NULL 比較には IS NULL を使う必要がある。
- 4C(マーケティング)
- 4P(Product/Price/Place/Promotion)を売り手視点から買い手視点に転換したフレームワークで、顧客価値(Customer Value)・顧客コスト(Cost to the Customer)・利便性(Convenience)・コミュニケーション(Communication)の4要素からマーケティング施策を検討する。ストラテジストは、自社が提供したい機能ではなく顧客が得る価値や負担を起点に施策を設計すべきだと判断する際に4Cの視点を用いる。
- 5-tuple
- 送信元IPアドレス・宛先IPアドレス・送信元ポート・宛先ポート・プロトコルの5つの値の組み合わせ。1つの通信フロー(コネクション)を一意に識別する基本単位で、ログやNetFlowレコードから侵害されたホストや通信を特定する出発点になる。
- 5フォース分析
- 業界の競争構造と収益性を、既存競合者間の敵対関係・新規参入の脅威・代替品の脅威・買い手の交渉力・売り手の交渉力という5つの競争要因から分析するフレームワーク。各要因が強いほど業界の収益性は圧迫されると考え、自社の事業戦略立案に用いる。
- 8進数(パーミッション表記)
- 0〜7の8種の数字で表す記数法。Linux のパーミッションは r=4・w=2・x=1 を足した8進3桁で表す(rwxr-xr-- は 754)。
- 100%ルール
- WBSの各階層で、下位要素の合計が上位要素のスコープを過不足なく100%表すべきという原則。抜け漏れや重複がある分解は見積りやスケジュールの精度を損なうため、WBS作成時に必ず適用すべき検証基準として重要。
- A/B テスト(Vertex AI)
- 同一エンドポイントに複数のモデルバージョンをデプロイし、トラフィック分割比率を指定して実際のリクエストで性能を比較する手法。指標が悪化すればトラフィックを即座に旧バージョンへ戻すロールバックが容易で、本番影響を抑えながら新モデルを検証できる。
- AAA(認証・認可・アカウンティング)
- ネットワーク機器やサービスへのアクセス制御を担う3つの機能の総称。認証(Authentication)は利用者が誰かを確認し、認可(Authorization)は確認済みの利用者に何を許可するかを決め、アカウンティング(Accounting)は実行内容を記録する。Cisco機器ではRADIUSやTACACS+をAAAサーバとして利用しこれらを一元管理する。
- ABAC(属性ベースアクセス制御)
- タグなどの属性に基づいてアクセスを動的に判断する方式。aws:PrincipalTag と aws:ResourceTag を条件で突き合わせ(例: 同じ部門タグなら許可)、ロールを増やさずスケールできる。ロール単位の RBAC と対比される。
- AC(実コスト)
- ある期間に完了した作業に対して実際に発生した(incurred)コストの累積値(支払い完了の有無は問わない)。EVと比較することでコスト効率(CPI)を、単独では予算執行状況を把握するために使う。
- Accelerated Networking
- SR-IOV により VM の NIC を高速化し、遅延を下げてスループットを上げる機能。SAP の低遅延要件に有効。NIC 帯域自体は VM サイズに依存する。負荷分散のロードバランサーとは別物。
- Access Approval
- Google 担当者がサポート等でデータへアクセスする前に、顧客側の明示的な承認を必須にする機能。Access Transparency が事後のログであるのに対し、Access Approval は事前の承認ゲートを追加する点が異なり、両者を組み合わせて主権性の高い統制を実現する。
- Access Context Manager
- デバイス・送信元 IP・地域などのコンテキスト(アクセスレベル)で、アクセスできる境界を定義する仕組み。VPC Service Controls や IAP と連携してゼロトラスト的な制御を実現する。
- Access Transparency
- Google のサポート/エンジニアリング担当者が、サポート対応等の理由で顧客データにアクセスした際の記録(誰が・いつ・なぜ・どのリソースに)をログとして提供する機能。監査要件や透明性の説明責任を果たすために有効化し、Cloud Logging から確認できる。
- ACI(Application Centric Infrastructure)
- Ciscoのデータセンター向けSDNアーキテクチャ。APIC(APIコントローラ)がSpine-Leafファブリック全体を集中管理し、アプリケーションの通信要件をポリシー(EPG・コントラクト)として定義してネットワーク全体へ自動反映する。REST APIやモデル駆動の仕組みで自動化・統合するのが前提。
- ACID
- トランザクションの信頼性を表す性質:原子性・一貫性・分離性・永続性。
- ACID特性
- トランザクションが満たすべき4つの性質、原子性(Atomicity)・一貫性(Consistency)・独立性(Isolation)・耐久性(Durability)の総称。障害や並行実行があってもデータベースの整合性を保証するための基本原則であり、DBMSのトランザクション管理機構がこれを実現する。
- ACL(アクセス制御リスト)
- ルーターやファイアウォールで、送信元/宛先IPアドレスやポート番号などの条件に基づき通信を許可(permit)または拒否(deny)するルールの並び。上から順に照合され、既定では最後に暗黙の拒否が適用される。
- ACR(Azure Container Registry)
- コンテナイメージを保存・管理するプライベートレジストリ。ACR Tasks でクラウド側ビルドができ、認証はマネージド ID を使う。
- action.yml(メタデータ)
- アクションのルートに必須のメタデータファイル。name・description・inputs・outputs・runs(using=node20/docker/composite)・branding を定義する。runs.using と実装が一致していないと起動しない。
- Actions のコスト最適化
- paths/branches フィルター・concurrency・キャッシュ・matrix の最小化・ランナーサイズの見直しで Actions の消費を抑える施策。品質を落とさず無駄を削るのが原則。
- ACTIONS_STEP_DEBUG
- シークレットに設定するとステップ実行のデバッグログを有効化する変数。通常ログで原因が分からない失敗の調査に使う。
- Active Assist とレコメンダー
- 使用状況を分析してインサイトと推奨(レコメンデーション)を自動提示する仕組み。アイドルリソースの削減、過大インスタンスの適正化(rightsizing)、IAM 過剰権限の縮小などを cost/security/performance/manageability/reliability の各カテゴリで提示する。
- Active Directory
- Windows環境でユーザーアカウント・コンピュータ・グループなどを一元管理するMicrosoftのディレクトリサービス。組織内の誰が何にアクセスできるかを管理するIDストアとして機能し、ログイン認証やアクセス権の割り当ての基盤になる。
- ADMX インポート(Intune)
- 管理用テンプレート(ADMX/ADML ファイル)で定義されたレジストリベースの設定を Intune に取り込み、構成プロファイルの「Imported Administrative templates」として展開できるようにする機能。Office など Settings Catalog に未収載のサードパーティ製 ADMX 設定も、カスタム ADMX として追加できる。
- Advanced Analytics(Intune Suite)
- Intune Suite のアドオンで、Endpoint Analytics の標準指標を拡張し、異常検出(anomaly detection)やデバイス障害の根本原因分析などプロアクティブな分析をエンドポイント全体に対して行う機能。問題が広範囲化する前に傾向を検知し、IT 部門に是正のきっかけを与える。
- Advisor for Teams
- 組織全体への Teams の大量展開を計画し、準備状況や推奨を確認する展開支援ツール。
- AD変換の分解能と量子化
- AD変換器(ADC)の分解能はビット数で表され、n ビットならアナログ入力範囲を2のn乗段階に区切って離散値に変換する。この段階化(量子化)に伴い元の値との差である量子化誤差が必然的に生じ、分解能を上げるほど誤差は小さくなるがコスト・変換時間が増える。センサ精度要件に対し必要十分な分解能を選ぶ設計判断が要る。
- Agent Evaluations
- エージェント型アプリケーションのタスク完了率、ツール呼び出しの適切さ、推論の質などを測る評価機能。RAG を含むエージェントの応答品質を人手や自動指標で継続的にチェックし、プロンプトやツール定義の改善に役立てる。
- Agent Mode
- ゴールを与えると、計画→編集→ビルド/テストで検証→修正を自律的に反復するモード。必要なファイルやコマンドも自ら判断する。
- Agents for Amazon Bedrock
- Amazon Bedrock Agents(旧 Agents for Amazon Bedrock)。タスクを段階に分解し、API(アクショングループ)やナレッジベースを呼び出して多段の処理を自律実行する Bedrock のエージェント機能。
- AH(認証ヘッダ)
- IPsecを構成するプロトコルの一つで、IPパケットの完全性と送信元認証を提供するが暗号化(機密性)は行わない。IPヘッダも認証対象に含むため、経路上でアドレスを書き換えるNATと整合せず相性が悪い。機密性が必要ならESPを用いる。
- AI Builder
- ローコードでアプリやフローに AI(フォーム/請求書読み取り・予測・分類・オブジェクト検出など)を追加する Power Platform の機能。
- AI Builder のモデル種別
- AI Builder で使える AI の種類。フォーム処理(書類からの抽出)・オブジェクト検出・予測・カテゴリ分類・テキスト認識などを、ローコードで学習・利用できる。
- AI Gateway(API Management)
- Azure API Management に配置し、Microsoft Foundry のモデルへのアクセスを集中的に認証・レート制限・監視・トークン課金管理する。バックエンドのモデルキーを隠蔽し利用を統制する。モデル/エージェント側の安全フィルタ(Foundry のガードレール)とは役割が異なる。
- AI インフラ(TPU)
- 大規模 AI の学習・推論を支える Google の専用ハードウェア。TPU(Tensor Processing Unit)が代表で、コストや持続可能性(電力)に関わる。
- AI ガバナンス
- 生成 AI を組織として統制する枠組み。モデルカード(用途・制約の文書化)、データ/モデルのリネージ(来歴追跡)、CloudTrail による監査証跡、承認フローとアクセス制御を組み合わせ、説明責任・コンプライアンス・再現性を担保する。
- AI サービスオプトアウトポリシー
- 組織(AWS Organizations)単位で、Amazon が AI/ML サービス改善のために顧客データを利用することを一括停止するポリシー。組織単位ポリシー(Organizations policy)の一種で、個々のアカウントごとに設定する手間を省き、データガバナンス要件への対応に使う。
- AI の可観測性(トレース/トークン監視)
- Application Insights や Foundry のトレースで、各リクエストのレイテンシ・トークン消費・コスト・エラーを記録し、品質と性能を継続監視する。
- AI 向けコンテナ/サーバーレスコンピュート
- 推論や AI パイプラインの実行基盤。Azure Container Apps(スケール対応・KEDA)や Azure Functions(イベント駆動)でモデル呼び出しや前後処理をサーバーレスに動かす。
- AI 向けベクトルデータ管理
- 埋め込みベクトルを保存し類似検索する基盤。Azure では Cosmos DB(NoSQL のベクトル検索)、PostgreSQL の pgvector、Azure AI Search のベクトルインデックスを用途で選ぶ。
- AI 出力の検証
- Copilot の出力を採用前に確認する必須運用要件。コードレビュー・テスト・セキュリティスキャン・事実確認で行い、生成テスト自体も検証する。
- AIのハルシネーション
- 生成AIが、事実に基づかない情報をもっともらしい文章として生成してしまう現象。出力結果を鵜呑みにせず、根拠を確認する(ファクトチェックする)利用者側のリテラシーが重要となる。
- AKS のセキュリティ
- AKS のネットワーク分離(プライベートクラスター・ネットワークポリシー)、Entra 連携の認証/認可、Defender for Containers による監視で、Kubernetes ワークロードを保護する。
- ALB の機能(ルーティング/スティッキー/ターゲットグループ)
- ALB のリスナールールはパス(/api/*)やホスト名で振り分け、ターゲットグループ単位で転送する。スティッキーセッション=同一クライアントを同じターゲットへ固定(Cookie)。X-Forwarded-For=元のクライアント IP を伝えるヘッダー。
- AlloyDB
- 高性能な PostgreSQL 互換のマネージドデータベース。
- ALM(アプリケーションライフサイクル管理)
- 開発→テスト→本番へとアプリを管理して移送する一連の運用。Power Platform ではソリューションと環境、パイプラインを使って実現する。
- ALTER DATABASE ... SET
- 特定のデータベース単位で設定パラメータを恒久的に上書きする DDL。そのデータベースへの全接続に適用される。適用優先順位は、より限定的な設定が優先され、session の SET > ALTER ROLE ... IN DATABASE(role+database)> ALTER ROLE(role)> ALTER DATABASE(database)> postgresql.conf の順になる。
- ALTER ROLE ... SET
- 特定のロール単位で設定パラメータを恒久的に上書きする DDL。そのロールで開始する全セッションに適用され、session-level の SET コマンドより永続的でスコープが広い。ALTER ROLE ... IN DATABASE ... SET で対象データベースをさらに限定することもできる。
- Always Encrypted
- Azure SQL の機密列(クレジットカード番号など)をクライアント側で暗号化し、サーバーに平文を見せない仕組み。鍵(列マスターキー)はクライアントや Key Vault に置く。サーバーは平文を扱えないため通常は等価検索などに限られ、範囲演算などには Secure Enclaves が必要。保存時のみ守る TDE と異なり、利用時(DBA に対しても)保護する点が特徴。
- Always Encrypted(VBS エンクレーブ)
- 仮想化ベースのセキュリティ(VBS)エンクレーブを使う Always Encrypted。暗号化したままサーバー側で範囲比較やパターン一致などの演算を可能にする。
- Always On 可用性グループ
- SQL Server on VM / Managed Instance で、複数レプリカ間でデータベース群を同期/非同期にレプリケートし HA/DR を構成する機能。
- Amazon API Gateway
- REST/HTTP/WebSocket API を作成・公開・管理するフルマネージドサービス。スロットリング・認可(Cognito/Lambda オーソライザー)・ステージ・使用量プラン・キャッシュを備える。バックエンドは Lambda 等。
- Amazon AppFlow
- SaaS アプリ(Salesforce・SAP・Zendesk 等)と AWS の間でデータを安全に転送するフルマネージドな統合サービス。コード不要でフローを構成する。
- Amazon Application Recovery Controller(ARC)
- マルチリージョン/マルチAZ アプリの可用性と災害復旧を制御するサービス。各セルの準備状況を継続監視し、ルーティングコントロールで安全にフェイルオーバー(トラフィックの切り替え)を実行できる。複雑なリカバリ操作を確実に行うためのガバナンスを提供する。
- Amazon Athena
- S3 上のデータに Presto/Trino ベースの SQL を実行するサーバーレスサービス。スキャンしたデータ量に応じて課金されるため、Parquet 化+パーティション分割でコストを大幅に削減できる。Glue データカタログをメタデータとして利用する。
- Amazon Augmented AI (A2I)
- 機械学習の推論結果に対する人手レビュー(Human-in-the-loop)のワークフローを構築するサービス。低信頼度の予測を人にレビューさせ、品質を担保する。
- Amazon Aurora
- MySQL/PostgreSQL 互換のクラウドネイティブ DB。ストレージは 3 AZ に 6 重複製で自動修復・自動拡張(最大128TiB)。最大15のリードレプリカ、フェイルオーバーは通常30秒未満。RDS より高可用・高性能。
- Amazon Bedrock
- 複数ベンダーの基盤モデルにAPIでアクセスし、自社アプリに生成AIを組み込むフルマネージドサービス。ナレッジベース(RAG)・エージェント・ガードレールも提供。
- Amazon Bedrock AgentCore
- 任意のフレームワーク(CrewAI/LangGraph/LlamaIndex/Strands 等)と任意のモデルで本番 AI エージェントを動かすエージェントプラットフォーム。モジュール式サービス=Runtime(サーバーレス・セッション分離)/Memory(短期・長期記憶)/Gateway(API・Lambda を MCP ツール化)/Identity(エージェント認証)/Code Interpreter/Browser/Observability を、インフラ管理なしで提供する。
- Amazon Bedrock Data Automation
- 文書・画像・音声・動画などの非構造化データから構造化出力を生成する自動処理ワークフロー。GenAI アプリのデータ準備を自動化する。
- Amazon Bedrock Knowledge Bases
- マネージドな RAG 機能。データソース(S3 等)を取り込み、チャンク分割・埋め込み生成・ベクトルストア(OpenSearch Serverless/Aurora pgvector 等)への格納・検索・出典付き回答までを Bedrock が一括で担う。自前の検索基盤を組まずに根拠付き生成を実現する。
- Amazon Bedrock Prompt Flows
- プロンプト・基盤モデル・ナレッジベース・Lambda を視覚的に連結して GenAI ワークフローを組む Bedrock のビルダー。working draft → version(イミュータブル)→ alias で本番化し、条件分岐や逐次チェーンを構成できる。
- Amazon Bedrock Prompt Management
- プロンプトをパラメータ化テンプレートとして作成・テストし、バージョンとエイリアスで管理・デプロイする Bedrock の機能。プロンプトを「資産」として版管理・比較・再利用できる。
- Amazon CloudFront
- CDN。エッジロケーションでコンテンツをキャッシュし、ユーザーへ低遅延で配信する。
- Amazon CloudWatch
- 可観測性の中核。Logs=ログ集約(Logs Insights でクエリ)、メトリクス=数値の時系列(カスタムメトリクスも)、アラーム=しきい値超過で通知/自動対応(SNS/Auto Scaling)。Lambda のログは自動で Logs へ。
- Amazon CodeGuru
- コード品質を補助するサービス。CodeGuru Reviewer(レビューでの欠陥・秘密情報指摘)は新規提供を終了し機能は Amazon Q Developer に統合、現行は CodeGuru Profiler(実行時の CPU/メモリのホットスポット特定)が中心。
- Amazon Cognito
- アプリのユーザー認証/認可。ユーザープール=サインアップ/サインイン(認証)で JWT を発行、アイデンティティプール=トークンを一時 AWS 認証情報に交換(AWS 認可)。外部 IdP とのフェデレーションや MFA に対応。
- Amazon Comprehend
- テキストを分析する用途別AIサービス(感情・エンティティ・キーフレーズ)。
- Amazon Data Firehose
- コード不要で S3/Redshift/OpenSearch などへストリームを配信するサービス。バッファリング・Lambda 変換・Parquet 変換ができるが、リプレイ用の保持はしない。
- Amazon Data Lifecycle Manager(DLM)
- EBS スナップショットや EBS-backed AMI の作成・保持・削除をポリシーで自動化するサービス。定期的なバックアップと保持期間を管理し、コンプライアンスやデータ保護(暗号化スナップショットの世代管理)を支援する。
- Amazon DataZone
- 組織横断のデータカタログ・ガバナンス・データ共有を提供するサービス。ビジネスカタログで資産を発見し、購読フローでアクセスを統制する。機能は次世代の Amazon SageMaker(統合スタジオ)へ統合が進む。
- Amazon Detective
- GuardDuty/CloudTrail/VPC フローログからエンティティの振る舞いグラフを構築し、検出(finding)を起点に攻撃の経緯・影響範囲・根本原因を時系列で調査するサービス。GuardDuty が「検知」、Detective が「調査」を担う。
- Amazon DevOps Guru
- 機械学習で運用データ(メトリクス/ログ/イベント)から異常な挙動や運用上の問題を検出し、原因と是正策を提示するサービス。
- Amazon DocumentDB
- MongoDB 互換のマネージドドキュメントデータベース。JSON ライクな柔軟なドキュメントを扱うワークロードに向く。
- Amazon DynamoDB
- サーバーレスなNoSQLキー値/ドキュメントDB。柔軟なスキーマで大規模でも低遅延。
- Amazon EBS
- ブロックストレージ。EC2 に接続する仮想ディスクで、1 ボリュームは原則 1 インスタンスに接続(io1/io2 は Multi-Attach で複数に接続可)。1 インスタンスに複数ボリュームは可。gp3/io2 等のタイプがあり、スナップショットでバックアップする。
- Amazon EC2
- 仮想サーバー(IaaS)。OSから上を自分で管理する最も自由度の高いコンピュート。購入オプション(オンデマンド/RI・Savings Plans/スポット)で最適化。
- Amazon ECR(Elastic Container Registry)
- コンテナイメージをバージョン管理して保管するレジストリ。イメージスキャン(Basic/Enhanced=Amazon Inspector 連携)で脆弱性を検出し、ライフサイクルポリシーで古いイメージを整理、タグのイミュータブル化で上書きを防ぐ。ECS/EKS のデプロイ元となる。
- Amazon ECS(Elastic Container Service)
- AWS ネイティブのコンテナオーケストレーション。タスク定義でコンテナを記述し、EC2 起動タイプ(自前管理)か Fargate 起動タイプ(サーバーレス)で実行する。タスク/サービス単位でスケールする。
- Amazon EFS
- ファイルストレージ。複数のEC2から同時マウントして共有できる(NFS)。
- Amazon EKS(Elastic Kubernetes Service)
- マネージド Kubernetes サービス。コントロールプレーンを AWS が運用し、ワーカーは EC2 か Fargate。既存の Kubernetes 資産・エコシステムをそのまま使いたい場合に選ぶ(ECS より複雑)。
- Amazon Elastic Transcoder
- メディア(動画)をデバイス向けフォーマットに変換するトランスコーディングサービス。2025年11月13日に提供終了済みで、後継は AWS Elemental MediaConvert。
- Amazon EMR
- Apache Spark/Hadoop/Hive/Presto などをクラスタで実行するマネージドビッグデータ基盤。超大規模なカスタム分散処理や既存 Hadoop/Spark 資産の移行に向く(軽量なサーバーレス ETL は Glue が手軽)。
- Amazon EventBridge
- イベント駆動アーキテクチャの中核となるサーバーレスのイベントバス。多数のソースからイベントを受け取り、ルールでフィルタして Lambda や Step Functions などへ配信し、サービス間を疎結合にする。
- Amazon Forecast
- 時系列予測に特化したマネージド ML サービス。過去の時系列と関連変数から需要・在庫・財務などの将来値を予測する(自前モデル構築不要)。2024-07 に新規受付を終了し、後継は SageMaker Canvas の時系列予測。
- Amazon Fraud Detector
- 機械学習でオンライン不正(不正アカウント・不正取引)を検出するマネージド サービス。
- Amazon FSx(ファイルシステム)
- マネージドなファイルシステム群。FSx for Windows File Server(SMB/AD)、FSx for Lustre(HPC・高速)、FSx for NetApp ONTAP、FSx for OpenZFS をワークロードで選ぶ。
- Amazon GuardDuty
- ログを分析して脅威を自動検出する。結果統合はSecurity Hub、脆弱性はInspector、機密データ検出はMacie。
- Amazon Inspector
- EC2・ECR コンテナイメージ・Lambda の既知の脆弱性(CVE)を継続的にスキャン・評価するサービス。検出結果は重大度スコア付きで Security Hub に集約でき、CI/CD パイプラインに組み込んで脆弱なイメージのデプロイをブロックできる。
- Amazon Kendra
- 自然言語で社内文書を検索できるインテリジェント検索サービス。多様なデータソースをコネクタで取り込み、質問に対して関連箇所を提示する(RAG の検索基盤にも使われる)。
- Amazon Keyspaces
- Apache Cassandra 互換のマネージドなワイドカラムデータベース。サーバーレスで、Cassandra の CQL を使うワークロードに向く。
- Amazon Lex
- 音声・テキストの会話ボット(チャットボット/IVR)を構築するサービス。意図(インテント)とスロットで対話を設計し、Lambda で処理を実装する。Alexa と同じ技術基盤。
- Amazon Lightsail
- 小規模ワークロード向けに、仮想サーバー・ストレージ・DB・ロードバランサーを定額・簡素にまとめて提供するサービス。
- Amazon Lookout シリーズ(Equipment / Metrics / Vision)
- 用途特化の異常検知 ML サービス群。Lookout for Equipment=センサーデータから設備異常を検知(2025-10 に新規受付終了、2026-10-07 に提供終了予定)。Lookout for Vision(画像の製品欠陥)と Lookout for Metrics(ビジネス指標の異常)は提供終了済み。
- Amazon Macie
- 機械学習で S3 内の機微データ(個人情報=PII、認証情報など)を検出・分類するサービス。データ保護のコンプライアンスを支援し、検出結果は Security Hub に集約して継続的に監視できる。
- Amazon Managed Blockchain
- Hyperledger Fabric や Ethereum のブロックチェーン ネットワークをマネージドに構築・運用するサービス。
- Amazon Managed Grafana
- フルマネージドな Grafana。CloudWatch・Prometheus・X-Ray など複数データソースのメトリクス/ログ/トレースを 1 つのダッシュボードで可視化・アラートできる。運用監視の「見える化」レイヤーを自前運用せずに使える。
- Amazon Managed Service for Prometheus (AMP)
- Prometheus 互換のマネージドなメトリクス収集/保存サービス。EKS/ECS などコンテナ環境のメトリクスを PromQL でクエリでき、スケールや保持を AWS に任せられる。Managed Grafana と組み合わせて可視化する構成が定番。
- Amazon Mechanical Turk
- クラウドソーシングで人手のタスク(データのラベル付け・検証など)を多数のワーカーに依頼するマーケットプレイス。ML 学習用のラベル付きデータ作成に使う。
- Amazon MemoryDB
- Redis 互換で耐久性のあるインメモリデータベース。超低遅延かつデータ永続化が必要なワークロードに向く(キャッシュ専用は ElastiCache)。
- Amazon MQ
- ActiveMQ/RabbitMQ 互換のマネージドなメッセージブローカー。既存の標準プロトコル(JMS/AMQP/MQTT 等)を使うアプリの移行に向く(新規の疎結合は SQS/SNS が一般的)。
- Amazon MSK
- マネージドな Apache Kafka。既存 Kafka ワークロードの移行や、Kafka 固有のエコシステムが必要な場合に選ぶ。
- Amazon MWAA(Managed Airflow)
- マネージドな Apache Airflow。DAG でデータパイプラインをスケジュール・編成する。既存の Airflow 資産を活かす場合に適する。
- Amazon Neptune
- フルマネージドのグラフデータベース。関係性(ソーシャルグラフ・推薦・不正検知・ナレッジグラフ)の問い合わせに最適化され、Gremlin/openCypher/SPARQL に対応する。
- Amazon OpenSearch Service
- 全文検索とログ分析/可観測性に強いマネージド検索エンジン。OpenSearch Dashboards(Kibana)で可視化する。大規模な集計分析の主役は Redshift で、OpenSearch は検索/ログ用途と使い分ける。
- Amazon Personalize
- リアルタイムのレコメンデーション(推薦)を機械学習で提供するマネージド サービス。
- Amazon Pinpoint
- メール/SMS/プッシュ/音声などマルチチャネルの顧客エンゲージメント(キャンペーン配信・分析)サービス。2025年に提供終了が発表され、機能は AWS End User Messaging や SES へ移行が進む。
- Amazon Polly
- テキストを自然な音声に変換する(音声合成・TTS)AI サービス。多言語・多数のニューラル音声を提供し、読み上げアプリや IVR に使う。
- Amazon Q
- 業務やコーディングを支援する、すぐ使える生成AIアシスタント(Amazon Q Business / Amazon Q Developer)。
- Amazon QuickSight
- サーバーレスな BI ダッシュボードサービス。Athena/Redshift/RDS などをデータソースに可視化し、SPICE(インメモリエンジン)で高速化、行/列レベルセキュリティで出し分け、Q(自然言語質問)や埋め込みにも対応。可視化が役割で、クエリエンジンそのものではない。
- Amazon RDS
- マネージドなリレーショナル(SQL)データベースサービス。MySQL・PostgreSQL・MariaDB・Oracle・SQL Server エンジンに対応し、パッチ適用・バックアップ・マルチ AZ 冗長化・リードレプリカを AWS が運用する。
- Amazon RDS Proxy
- RDS/Aurora へのコネクションをプールして共有するフルマネージドプロキシ。多数の接続を抱える Lambda などでコネクション枯渇を防ぎ、フェイルオーバー時間も短縮する。IAM 認証・Secrets Manager 連携。
- Amazon Redshift
- ペタバイト級のデータウェアハウス(OLAP)。列指向ストレージと MPP(並列処理)で大規模集計を高速化する。Redshift Spectrum で S3 を直接クエリ、Serverless でプロビジョニング不要。
- Amazon Rekognition
- 画像・動画を分析する用途別AIサービス(物体・顔・不適切コンテンツの検出)。
- Amazon Route 53
- DNS(ドメイン名の解決)とドメイン登録のサービス。ヘルスチェックやルーティングポリシーも持つ。
- Amazon S3
- オブジェクトストレージ。画像・バックアップ・配布物を高耐久で保存しHTTP(S)でアクセス。ストレージクラス(Standard/IA/Glacier)でコスト最適化。
- Amazon S3 Tables
- Apache Iceberg 形式の表形式データを S3 上でマネージドに保存・最適化するストレージ。分析エンジン(Athena/EMR/Spark 等)から効率的にクエリでき、自動コンパクションでテーブルを最適化する。
- Amazon SageMaker
- MLモデルの構築・学習・デプロイを一気通貫で行うマネージド環境(自社データで独自モデル)。JumpStartで事前構築モデルを試す/微調整も。
- Amazon Security Lake
- セキュリティログ/イベントを、専用アカウントの S3 データレイクへ自動収集・正規化(OCSF 標準スキーマ)するサービス。VPC Flow Logs・CloudTrail・Route 53・各種 AWS/サードパーティのセキュリティデータを一元集約し、Athena/OpenSearch 等で横断分析できる。
- Amazon SES(Simple Email Service)
- スケーラブルなメール送受信サービス。トランザクションメールやマーケティングメールを高い到達率で送信し、バウンス/苦情を管理する。
- Amazon SNS
- パブリッシュ/サブスクライブのメッセージング。1つのメッセージを多数の購読者へファンアウトする(プッシュ型・1対多)。SNS+SQS でファンアウト構成。
- Amazon SQS
- フルマネージドなメッセージキュー。生産者と消費者を疎結合にし、作業をバッファしてスパイクを吸収する(プル型・基本1対1)。
- Amazon Textract
- 書類・帳票からテキストや項目を抽出する用途別AIサービス(OCR+構造抽出)。
- Amazon Timestream
- 時系列データ専用のマネージド データベース。IoT やメトリクスの大量の時系列を効率的に保存・分析する。
- Amazon Titan Text Embeddings
- テキストを意味ベクトルに変換する Bedrock の埋め込みモデル。RAG の文書/クエリのベクトル化に使い、次元数や正規化が検索の精度・コスト・ストレージに影響する。クエリと文書を同じモデルで埋め込むのが原則。
- Amazon Transcribe
- 音声をテキストに変換する(音声認識)AI サービス。通話・会議・メディアの文字起こしに使い、話者分離やカスタム語彙、リアルタイム/バッチに対応する。
- Amazon Translate
- 言語間でテキストを翻訳するニューラル機械翻訳サービス。リアルタイム/バッチ翻訳やカスタム用語に対応し、多言語対応アプリに組み込む。
- Amazon Verified Permissions
- アプリケーションの認可(誰が何をできるか)を外部化するマネージドサービス。Cedar ポリシー言語でファイングレインなアクセス制御を定義し、アプリのコードから分離して一元管理・監査できる。
- Amazon VPC
- AWS内に作るプライベートネットワーク。サブネット(公/私)で区切り、セキュリティグループ/NACLで通信を制御する。
- Amazon VPC IPAM
- IP アドレス空間を組織全体で計画・割り当て・追跡・監視するサービス。重複 CIDR を防ぎ、プールを階層化してアカウント/リージョンに自動割り当てする。
- AMI の配布と寿命(コピー/共有/廃止)
- AMI の配布と寿命管理。AMI コピー=別リージョン/アカウントへ複製(暗号化や DR に)。起動許可(Launch Permission)=他アカウントへ共有。廃止(deprecate)=新規利用を促さないが既存は使える。登録解除(deregister)=AMI を使用不可にする。
- AMI(ゴールデンイメージ)
- EC2 インスタンスの起動元となるマシンイメージ。OS とソフトを事前構築したゴールデン AMI は高速起動と構成統一に役立つ。AMI はリージョン単位で、別リージョンではコピーが必要。
- Analyst(組み込みエージェント)
- Microsoft 365 Copilot の組み込みエージェントの一つ。生データを分析・可視化し、コードインタープリターを使って表計算やレポート作成を支援する。
- Analytics Hub
- BigQuery のデータセットを、コピーを作らずに社内外の他組織と安全に共有・受領できるサービス。
- Android Enterprise の登録種別
- Android の管理形態。fully managed(法人所有・全体管理)/ dedicated(単一用途のキオスク)/ corporate-owned work profile(法人所有で業務/個人分離)/ personally-owned work profile(個人所有で業務領域分離)を所有形態と用途で選ぶ。
- Ansible(ネットワーク自動化)
- YAML形式のPlaybookに望ましい構成を宣言的に記述し、SSHやAPI経由でエージェント不要(エージェントレス)に多数のネットワーク機器へ一括適用する構成管理ツール。Pythonで書かれたモジュールが機種ごとの差異を吸収し、同じPlaybookを繰り返し実行しても結果が変わらない冪等性を重視する。
- Apache HTTPサーバー
- Linux で広く使われる Web サーバーソフトウェア(httpd/apache2)。httpd.conf で仮想ホストや認証、アクセス制御を設定し、apachectl/apache2ctl で制御する。
- Apache Kafka コネクタ(Cosmos DB)
- Apache Kafka と Cosmos DB を接続し、ストリーミングのイベントデータをリアルタイムに取り込む/送出するコネクタ。バッチ移行の ADF/Synapse パイプラインと使い分ける。
- API Gateway キャッシュ
- ステージ単位で有効化する応答キャッシュ。指定した TTL の間、同一リクエストへバックエンド(Lambda 等)を呼ばず保存済みの応答を返し、レイテンシとバックエンド負荷を削減する。キャッシュサイズは 0.5GB〜237GB から選び、時間課金が発生する。
- API Gateway ステージ
- API の特定のデプロイをひも付ける名前付き環境(dev/prod 等)。ステージ変数でバックエンドの接続先を環境ごとに切り替えられ、トラフィックの一部だけ新デプロイへ流すカナリアリリースにも対応する。ステージごとに個別の設定(スロットリング・ログレベル)を持てる。
- API Gateway の機能(ステージ・スロットリング・統合)
- ステージ(dev/prod 等)でデプロイを分け、ステージ変数で切り替える。スロットリングとキャッシュで保護・高速化し、Lambda プロキシ統合やマッピングテンプレートでリクエスト/レスポンスを変換、CORS を構成する。
- API Gateway の種類(REST/HTTP/WebSocket)
- REST API は機能が豊富(使用量プラン・APIキー・リクエスト検証)、HTTP API は低遅延・低コストでシンプル、WebSocket API は双方向のリアルタイム通信に対応する。
- API Gateway(Google Cloud)
- サーバーレスのバックエンド(Cloud Run/Functions/App Engine)の前段に置くフルマネージドな API ゲートウェイ。OpenAPI で定義し認証・鍵・モニタリングを担う。
- API キーと使用量プラン
- API キーはクライアントを識別するトークンで、単体では認証にならず使用量プランと組み合わせてレート制限(1 秒あたりのリクエスト数)とクォータ(月間上限等)を課す。認証自体は Lambda オーソライザーや IAM、Cognito オーソライザーが別途担う。
- API リクエスト検証(入力ガード)
- 生成 AI を呼ぶ前に入力を検証する防御。API Gateway のリクエスト検証やスキーマ検査、長さ/形式チェック、Guardrails の入力フィルタで、過大入力・不正・プロンプトインジェクションを呼び出し前に弾く。コストと攻撃面を減らす。
- Apigee
- API を安全に公開・管理し、利用状況の計測やアクセス制御を一元化する API 管理プラットフォーム。
- APIM ポリシー
- API の挙動を XML で制御する仕組み(インバウンド/バックエンド/アウトバウンド/エラー)。認証(validate-jwt)・レート制限・変換・キャッシュ・CORS を適用する。
- APIレート制限とページネーション
- APIレート制限は単位時間あたりのリクエスト数に上限を設け、超えると429エラーで拒否する仕組み。クライアントは制限に応じたリトライ(バックオフ)が必要になる。ページネーションは大量の結果を一度に返さず、1回の応答件数を制限してページ単位(またはトークン単位)で分割取得させる仕組みで、いずれもAPIを消費する側が意識すべき利用上の制約。
- App attach
- アプリをパッケージ化してストレージに置き、ログイン時に動的にマウントする Azure Virtual Desktop のアプリ配信手法(旧 MSIX app attach の進化形)。イメージを作り直さずにアプリを更新/追加でき、ユーザー/グループへの割り当てで配信を制御する。
- App Control for Business
- 実行を許可するアプリ・ドライバー・スクリプトを事前に定義し、それ以外の実行を既定でブロックする許可リスト(allowlist)方式のアプリケーション制御機能(旧称 Windows Defender Application Control/WDAC)。マルウェアや未承認ソフトの実行を根本から防ぐゼロトラスト寄りの対策で、Intune からポリシーを配布できる。
- App Engine
- フルマネージドな Web アプリ基盤(PaaS)。サーバー管理なしにアプリを公開でき、開発に集中できる。
- App Service Environment(ASE)
- 専用かつ分離された App Service の実行環境。仮想ネットワークに統合され、ネットワーク分離や高いスケールが必要な機密ワークロードに使う。
- App Service の構成(設定・TLS・接続)
- アプリ設定・接続文字列(環境変数として注入)、カスタムドメインの TLS/証明書、サービス接続などを構成する。機密は Key Vault 参照にできる。
- App Service の自動スケール
- 負荷に追従してインスタンス数を増減する仕組み。ルールベースの Autoscale(CPU/メモリ等のメトリックやスケジュール条件で増減)と、プラットフォーム任せの自動スケーリングが選べる。コストと性能を両立する。
- App Service へのデプロイ
- コードやコンテナーを App Service に配置する方法(ZIP デプロイ・コンテナーデプロイ・CI/CD)。スロットと組み合わせて無停止化する。
- Apple Business Manager
- 組織が購入した Apple デバイスを Jamf・Intune 等の任意の MDM ソリューションと連携させ、開梱すると自動的に Automated Device Enrollment(旧 DEP)で登録・構成される Apple の Web ポータル。アプリ・書籍のライセンス管理(旧称 Volume Purchase Program/VPP。現在は ABM 内の「Apps and Books」に統合)もここから行い、デバイスとアプリの両方を一元的に企業管理へ組み込める。
- Apple Volume Purchase Program(VPP)
- Apple App Store の有料/無料アプリを組織単位でまとめて購入し、Apple Business Manager 経由で Intune に同期してデバイス/ユーザーへライセンス割り当て・回収できる仕組み。個人の Apple ID を使わせず(デバイスベース割り当て)に配布できるため、BYOD でも組織のプライバシーを侵害せずアプリ展開できる。
- Application Discovery Service
- オンプレミス環境の構成・使用状況を収集する移行前調査サービス。サーバーの CPU・メモリ・ネットワーク依存関係を把握し、移行計画の入力にする。
- Application Gateway
- L7(HTTP)のリージョン内ロードバランサー。URL パスベースルーティング・リスナー・HTTP 設定・SSL 終端・書き換え規則・WAF に対応する。
- Application Insights
- アプリの APM サービス。要求・依存関係・例外・メトリック・ログ・トレースを収集して性能と障害を分析する。Azure Monitor の一部。
- Application Load Balancer(ALB)
- L7 のロードバランサ。ホスト/パスベースルーティング、ターゲットグループ、スティッキーセッション、認証統合(OIDC/Cognito)に対応し、HTTP アプリの振り分けに使う。
- Application Migration Service(MGN)
- オンプレや他クラウドのサーバーを、エージェントによるブロックレベルの継続レプリケーションで EC2 へリホストする主力サービス。テスト起動で検証し、切替(cutover)時のダウンタイムを最小化する。
- Appointments with Microsoft Teams(予約)
- Teams の Virtual Appointments(Bookings 連携の仮想予約)機能。顧客や来訪者が事前に時間枠を予約し、その時刻にビデオ会議形式で担当者とやり取りを行う。1対1に限らずグループ予約、SMS通知、仮想ロビー、キュー表示(担当者向けの予約・待機状況管理)などにも対応し、来店・窓口対応をバーチャル会議に置き換える用途(銀行の相談窓口、店舗の来店予約等)で使われる。
- Apps Script
- Google Workspace 向けの JavaScript ベースの自動化・拡張プラットフォーム。Gmail/Drive/Sheets などを横断するスクリプトやアドオンを作成できる。
- AppSheet
- Google のノーコード アプリ開発プラットフォーム。スプレッドシートやデータベースから業務アプリや自動化を作成でき、Workspace 管理者は OU 単位で有効化を制御する。
- apt(Debian 系)
- Debian/Ubuntu 系のリポジトリ利用パッケージ管理。apt update は索引の更新(本体は更新しない)、apt upgrade はパッケージ本体の更新、install/remove/purge。apt-cache で検索、apt-file でファイルを含むパッケージを未インストールも含め逆引きする。リポジトリ定義は /etc/apt/sources.list。
- APT(高度で持続的な脅威)
- 特定の標的に対し、長期間にわたり気付かれないよう潜伏しながら情報窃取等を続ける高度で持続的な脅威(Advanced Persistent Threat)。国家の支援を受けた攻撃者集団が関与することが多く、単発の攻撃と異なり執拗さと高度な技術力を特徴とする。
- APサーバー
- Web3層モデルの中間層で、業務ロジック(アプリケーション処理)を実行するサーバー。Web サーバーからリクエストを受け取り、DB サーバーとやり取りして結果を返す。
- ARM Cortexシリーズ(M/R/A)
- ARMアーキテクチャの用途別プロセッサ群。Cortex-Mは低消費電力・低コストのマイコン向け、Cortex-Rはハードリアルタイム性を要する制御用途向け、Cortex-Aは高性能・OS実行(Linux/Android等)向けに設計されている。組込み設計ではリアルタイム性・処理性能・消費電力の要件に応じてシリーズを選定する。
- ARM テンプレート
- Azure リソースの構成を JSON で宣言的に記述する IaC の基盤形式。同じテンプレートを何度デプロイしても同じ状態に収束する冪等性を持ち、パラメーターファイルで環境ごとの値を切り替える。デプロイは増分(既定)または完全モードで、完全モードはテンプレートに無いリソースを削除する点に注意。
- ARP
- IPv4で、宛先IPアドレスに対応するMACアドレスを問い合わせて解決するプロトコル。ARP要求をブロードキャストし、該当ホストがARP応答で自分のMACを返す。解決結果はARPテーブルにキャッシュされる。IPv6ではNDPが同等の役割を担う。
- ARPスプーフィングと対策
- 偽装したARP応答をLANに送り、被害端末のARPテーブルにIPアドレスと攻撃者MACの誤った対応を登録させ、通信を攻撃者経由に中継させる(中間者攻撃の入口)攻撃。対策はスイッチのDHCPスヌーピングで作った正当なIP-MAC対応表を用い、ダイナミックARPインスペクション(DAI)で不正なARPを遮断すること。
- Artifact Analysis
- コンテナイメージやパッケージの既知の脆弱性を検出するスキャン。Binary Authorization(署名済みのみデプロイ可)とは役割が別で、検出と強制を組み合わせて使う。
- Artifact Registry
- コンテナイメージや言語パッケージを保存・管理するレジストリ。Cloud Build でビルドした成果物の保存先。
- AssumeRole
- STS の API 操作で、指定した IAM ロールを引き受けて一時認証情報を得る仕組み。信頼ポリシーで引き受け元を限定する。クロスアカウントや第三者アクセスの基礎。
- Assured Workloads
- 規制要件(データ所在地・人員管理・主権など)を満たす管理された環境でワークロードを動かす Google Cloud のサービス。コンプライアンス対応に使う。
- at/anacron
- at は一度だけの実行予約(at 23:00・at now + 2 hours。atq で確認、atrm で取消。制限は at.allow/at.deny)。anacron は日単位以上の周期を間隔で管理し、電源オフで飛んだ実行を起動後に埋め合わせる(設定は /etc/anacrontab)。
- Athena(パーティション/ワークグループ/CTAS)
- S3 を SQL で直接クエリする Athena の要点。パーティション分割とカラムナ形式(Parquet)でスキャン量=コストを削減。ワークグループでクエリの分離・コスト上限・課金分けを管理。CTAS で結果から新テーブル作成、Federated Query で他データソースも横断。
- Aurora のエンドポイント(クラスター/リーダー/カスタム)
- Aurora の接続先。クラスター(ライター)エンドポイント=書き込み先(フェイルオーバーで自動追従)。リーダーエンドポイント=読み取りをレプリカ群へ負荷分散。カスタムエンドポイント=任意のインスタンス集合(分析用など)をグループ化。用途で使い分ける。
- Aurora の機能(Serverless / Global Database)
- Aurora は 3 AZ に 6 重複製する高耐久 DB。Aurora Serverless v2 は負荷に応じ自動スケール、Global Database は複数リージョンへ低遅延複製して DR と読み取りを支える。
- Auto Scaling
- 需要や障害に応じてEC2などの台数を自動で増減する(弾力性)。ELBと組み合わせて高可用性に。
- Auto Scaling スケーリングポリシー
- Auto Scaling の増減方式。ターゲット追跡=指標を目標値に保つ(推奨・最も簡単)、ステップスケーリング=超過幅に応じ段階的に増減、シンプルスケーリング=1回調整してクールダウン待ち、スケジュールスケーリング=時刻ベース、予測スケーリング=ML 予測。
- Auto Scaling のキャパシティ設定(最小/希望/最大)
- Auto Scaling グループの台数設定。最小=下限、最大=上限、希望容量=現在維持したい台数。スケーリングは希望容量を最小〜最大の範囲で増減させる。
- Auto Scaling のポリシーとライフサイクルフック
- スケーリング方式=ターゲット追跡(指標を目標値に維持)・ステップ・スケジュール・予測。ライフサイクルフックで起動/終了時に初期化や排出(ドレイン)を挟む。
- Auto Scaling 終了ポリシー
- スケールイン時にどのインスタンスを終了するか決める規則。OldestInstance・NewestInstance・OldestLaunchTemplate(旧 OldestLaunchConfiguration)・AllocationStrategy・Default から選ぶ(ClosestToNextInstanceHour は秒単位課金の現在は意義が薄い)。スケールイン保護で特定インスタンスを除外できる。
- auto_explain
- 実行時間があらかじめ設定したしきい値(log_min_duration)を超えたクエリの実行計画を自動的にログへ出力する拡張。個々のクエリに EXPLAIN を付け直さなくても、本番環境で発生した遅いクエリの計画を事後に確認できる。shared_preload_libraries への登録が必要。
- autofix(Copilot Autofix)
- 検出した脆弱性に対する修正案を自動提示する機能。開発者はレビューして採用するが、提案も誤り得るため検証してからマージする。
- Automatic Model Tuning(HPO)
- ハイパーパラメーターを自動探索する機能。ベイズ最適化・ランダム・グリッド・Hyperband の戦略で、目標メトリックを最大/最小化する構成を見つける。
- AutoML のタスク(表形式/画像/NLP)
- 自動機械学習は表形式データだけでなく、コンピュータービジョン(画像分類・物体検出)や自然言語処理にも適用でき、アルゴリズムと前処理を自動探索する。
- autovacuum
- テーブルの更新・削除量が閾値(autovacuum_vacuum_threshold 等)を超えると VACUUM/ANALYZE を自動実行するバックグラウンドプロセス群。多くの場合、手動 VACUUM の負担を大幅に軽減し肥大化と統計の陳腐化を防ぐ(大量更新など特定のワークロードでは手動 VACUUM が依然必要な場合もある)。
- AVD Insights
- Azure Monitor 上のワークブックで、Azure Virtual Desktop の接続性能・ホスト使用率・ユーザーの接続失敗などを可視化する運用ダッシュボード。Log Analytics へのデータ送信が前提。汎用の Azure Monitor とは役割が異なる。
- AWS Agent Squad
- 複数の AI エージェントを協調させる OSS のオーケストレーションフレームワーク(旧 Multi-Agent Orchestrator)。Classifier が入力と会話履歴から最適なエージェントを動的に選び、SupervisorAgent が並列協調する。
- AWS Amplify
- フロントエンド/フルスタックの Web・モバイルアプリを素早く構築・ホスティングするフレームワークとサービス群(認証・API・ストレージの統合)。
- AWS App Mesh
- マイクロサービス間の通信を標準化するサービスメッシュ。Envoy プロキシをサイドカーとして各サービスに配置し、可観測性(メトリクス・トレース)やトラフィック制御(カナリアデプロイ・リトライ)をアプリコードの変更なしに提供する。2026年9月30日にサポート終了予定で、後継として ECS Service Connect や Amazon VPC Lattice が案内されている。
- AWS App Runner
- ソースコードまたはコンテナイメージから Web アプリ/API を自動でビルド・デプロイ・スケールするフルマネージドサービス。インフラ(ロードバランサー/オートスケール/証明書)を意識せずコンテナ化アプリを公開でき、ECS/Fargate より運用負荷が低い。DevOps では「簡単なコンテナ Web サービスを最小運用で動かす」選択肢。
- AWS App2Container (A2C)
- 既存の Java/.NET アプリを分析してコンテナ化(Dockerfile・ECS/EKS デプロイ用アーティファクト・CI/CD パイプライン雛形を生成)する移行ツール。レガシーアプリのモダナイズ(コンテナ化)を自動化する。
- AWS AppConfig
- アプリ構成とフィーチャーフラグを安全に配信する Systems Manager の機能。検証・段階的ロールアウト・自動ロールバック(CloudWatch アラーム連動)でリスクを抑える。
- AWS AppSync
- マネージドな GraphQL(および Pub/Sub)API サービス。複数データソースを 1 つの API に集約し、リアルタイム購読やオフライン同期をサポートする。
- AWS Artifact
- AWSのコンプライアンス報告書や契約(ISO/SOC等の監査証跡)をオンデマンドで入手できる。
- AWS Audit Manager
- PCI DSS/HIPAA/SOC 2 等の規制フレームワークに対する監査証拠を継続的に収集・整理し、監査レポート作成を支援するサービス。構成準拠の評価(Config)や検出の集約(Security Hub)とは役割が異なる。
- AWS Backup
- 複数サービス(EBS/RDS/DynamoDB/EFS 等)のバックアップを集中管理するサービス。バックアッププランでスケジュールと保持を定義し、クロスリージョン/クロスアカウントコピーや、削除を防ぐ Backup Vault Lock(WORM)に対応する。
- AWS Backup Audit Manager
- バックアップが組織のポリシー(頻度・保持・暗号化・クロスリージョン)に準拠しているかを継続評価し、コンプライアンスレポートを生成する機能。未保護リソースや逸脱を検出し、監査要件に応える。
- AWS Batch
- バッチ コンピューティング ジョブを、必要なコンピュート(EC2/Fargate/スポット)を自動でプロビジョニングしながら大規模に実行・スケジュールするマネージド サービス。
- AWS Billing and Cost Management
- 請求・コスト管理の総称。請求ダッシュボード・コスト配分タグ・予算(Budgets)・コスト分析(Cost Explorer)を含み、ML 学習/推論のコストを把握・配分・最適化する。
- AWS Budgets
- コスト/使用量/RI・SP カバー率に予算しきい値を設け、超過(または予測超過)でアラート通知するサービス。Budget Actions で IAM ポリシー適用や停止などの自動対応も可能。
- AWS CDK(Cloud Development Kit)
- TypeScript/Python 等のプログラミング言語でインフラを記述し、CloudFormation テンプレートを合成する IaC フレームワーク。コンストラクト(L1=生 CFn/L2=高水準/L3=パターン)で部品化・再利用でき、CDK Pipelines で自己更新型の CI/CD を組める。
- AWS Certificate Manager(ACM)
- SSL/TLS 証明書を無料で発行・自動更新するサービス。ELB・CloudFront・API Gateway に統合され、証明書の有効期限切れによる障害を防ぐ。自動更新は DNS 検証が確実(メール検証でも条件付きで自動更新可)。
- AWS Chatbot
- 運用通知やアラームを Slack や Microsoft Teams に連携するサービス(現在は「Amazon Q Developer in chat applications」に改名)。SNS 経由の通知や CloudWatch のグラフをチャットに流し、承認済みコマンドをチャットから実行できる(ChatOps)。
- AWS CLI
- AWS のサービスをコマンドラインから操作する公式ツール。プロファイル/認証情報・リージョン設定を持ち、シェルスクリプトや CI/CD ステップでの自動化に使う。`aws <service> <operation>` 形式で API を直接呼び、JSON 出力を jq 等で加工できる。
- AWS Client VPN
- リモートユーザーの端末から VPC やオンプレへ安全に接続するマネージド OpenVPN ベースのサービス。証明書相互認証や Entra/AD フェデレーション、認可ルールでアクセスを制御する。
- AWS Cloud Adoption Framework(AWS CAF)
- クラウド導入を組織的に進める AWS の指針。6 つの視点(ビジネス・人材・ガバナンス・プラットフォーム・セキュリティ・運用)で能力のギャップと移行計画を整理する。
- AWS Cloud Map
- アプリケーションのリソース(マイクロサービス、データベースなど)を動的に登録し、名前から現在の場所(IP/ポート/ARN)を解決するサービスディスカバリサービス。ECS/EKS のタスクがスケールイン/アウトしても、クライアントは論理名で最新のエンドポイントを検索できる。
- AWS Cloud WAN
- グローバルなネットワークをポリシーで一元管理するサービス。コアネットワークとセグメント(分離されたルーティングドメイン)で、複数リージョン・複数アカウント・オンプレを統合する。
- AWS CloudFormation
- 宣言的テンプレート(YAML/JSON)でリソース群(スタック)を再現性よくデプロイする IaC サービス。変更セットで適用前の差分を確認し、ドリフト検出で実体との乖離を発見する。ネストスタックや StackSets で構成を分割・多アカウント展開できる。
- AWS CloudHSM
- 専有(シングルテナント)のハードウェアセキュリティモジュールを提供するサービス。FIPS 140-2 Level 3、独自の鍵階層、鍵の物理的占有が規制で必須といった厳格な要件で使う。KMS のカスタムキーストアとしても連携できる。
- AWS CloudShell
- マネジメントコンソール内で開く、認証済みのブラウザシェル。AWS CLI・主要ランタイム・永続ストレージが事前構成されており、ローカルに鍵を置かずに素早く運用コマンドやスクリプトを実行できる。
- AWS CloudTrail
- アカウント内のAPI操作の監査ログ(誰が・いつ・何をしたか)を記録する。
- AWS CodeArtifact
- 依存パッケージ(npm/pip/Maven/NuGet 等)を一元管理するアーティファクトリポジトリ。アップストリームに公開リポジトリを設定して透過的にプロキシ・キャッシュでき、社内パッケージと公開パッケージを 1 つのエンドポイントに統合する。
- AWS CodeBuild
- フルマネージドなビルド/テストサービス。buildspec.yml に定義した手順でソースをコンパイル・テストし、成果物を出力する。従量課金でビルドサーバーの管理が不要。
- AWS CodeStar
- プロジェクトのテンプレートと統合ダッシュボードで CI/CD ツールチェーンを定型立ち上げした仕組み。2024年7月31日に提供終了済みで、後継は Amazon CodeCatalyst(統合 DevOps)やマネジメントコンソールでの個別サービス構成。
- AWS Compute Optimizer
- EC2・EBS・Lambda・Auto Scaling グループなどの使用状況を機械学習で分析し、過剰/不足プロビジョニングを検出して適切なサイジングを推奨するサービス。コスト最適化の起点となる。
- AWS Config
- リソースの構成を記録し、ルールへの準拠状況を評価する(構成変化の追跡)。
- AWS Config ルールと自動修復
- リソース構成を継続的に評価する Config ルール(マネージド/カスタム)で準拠状況を判定し、コンフォーマンスパックで束ね、SSM Automation で非準拠を自動修復する。
- AWS Control Tower
- マルチアカウント環境のセットアップと統制を自動化するサービス。ランディングゾーンを構築し、ガードレール(必須/推奨の予防・検出統制)を一括適用してベストプラクティスに沿った組織を素早く立ち上げる。
- AWS Copilot(CLI)
- コンテナ化アプリを ECS/Fargate/App Runner 上に構築・デプロイ・運用するためのコマンドラインツール。サービス種別(Load Balanced Web Service など)と環境(test/prod)を宣言するだけで、裏側の CloudFormation・パイプライン・ロギングを生成する。GitHub Copilot とは無関係。
- AWS Cost Explorer
- コストと使用量を時系列・サービス別・タグ別に可視化し、傾向分析や予測ができるツール。RI/Savings Plans の推奨や、リザーブド使用率/カバー率レポートも提供する。
- AWS Data Exchange
- サードパーティのデータ製品を検索・購読し、AWS 上で安全に受領・利用できるデータマーケットプレイス。外部データセットを分析基盤に取り込む。
- AWS DataSync
- ファイルやオブジェクトを、ネットワーク経由で高速・増分・整合性チェック付きで転送するサービス。NFS/SMB/S3/EFS/FSx 間を結び、回線が十分な場合のオンライン移行に向く。
- AWS Device Farm
- 実機のモバイル端末/ブラウザでアプリをテストできるクラウド テスト サービス。
- AWS Direct Connect
- オンプレミスと AWS を専用線で直結するネットワークサービス。インターネットを経由しないため低遅延・安定した帯域を得られ、大容量データ転送や一貫した遅延が必要なワークロードに向く。冗長化には複数ロケーションからの接続や Site-to-Site VPN との併用(フェイルオーバー)が推奨される。
- AWS Directory Service
- マネージドなディレクトリ群。AWS Managed Microsoft AD(本格的な Active Directory)、AD Connector(既存オンプレ AD へのプロキシ)、Simple AD(小規模向け)から選ぶ。EC2 のドメイン参加や AWS アプリの ID 連携に使う。
- AWS DMS(Database Migration Service)
- データベースの移行と継続的レプリケーションを行うサービス。CDC(変更データキャプチャ)で差分だけを取り込み、ソース DB を止めずに同期できる。スキーマ変換が要る場合は SCT(Schema Conversion Tool)を併用する。
- AWS Elastic Beanstalk
- コードをアップロードするだけで環境のプロビジョニングからデプロイまで自動化する PaaS。デプロイ方式(All-at-once/Rolling/Immutable/Traffic splitting)を選べ、.ebextensions で設定をコード化できる。
- AWS Elastic Disaster Recovery (DRS)
- ブロックレベルの継続的レプリケーションでサーバーを AWS に複製し、災害時に短い RTO/RPO で起動・フェイルオーバーできる DR サービス(CloudEndure DR の後継)。普段は低コストのステージング領域で待機し、必要時にフルキャパシティで復旧する。
- AWS Fargate
- ECS/EKS のサーバーレス実行基盤。EC2 インスタンスの管理(パッチ・スケール)が不要で、タスク単位の vCPU/メモリ指定だけで動く。運用負荷を下げたいときの第一選択。
- AWS Fault Injection Simulator (FIS)
- マネージドなカオスエンジニアリング/障害注入サービス。CPU 負荷・インスタンス停止・API スロットリング・AZ 障害などを実験テンプレートとして定義し、停止条件(ガードレール)付きで本番相当環境のレジリエンスを検証する。DevOps の「壊して学ぶ」回復力テストに使う。
- AWS Firewall Manager
- WAF・Shield Advanced・セキュリティグループ・Network Firewall・Route 53 Resolver DNS Firewall のルールを、組織(Organizations)全体に一元適用・強制するサービス。新規アカウントにも自動適用できる。
- AWS Global Accelerator
- 2 つの静的 anycast IP を提供し、ユーザーを最寄りエッジから AWS バックボーンに乗せて最適リージョンへ低遅延で届けるサービス。TCP/UDP の任意ポートに対応し、ヘルスチェックに基づく秒単位の高速リージョンフェイルオーバーが可能(キャッシュはしない)。エンドポイントグループのトラフィックダイヤルで流量を絞る。
- AWS Glue
- サーバーレス ETL の中核。クローラがスキーマを推論してデータカタログ(中央メタデータ・Athena/Redshift Spectrum/EMR が共有)に登録、ETL ジョブがサーバーレス Spark で変換/クレンジング、Glue Data Quality(DQDL)でデータ品質を検証、ジョブブックマークで処理済みデータの重複を防ぐ。
- AWS Glue DataBrew
- コードなしの視覚的データ準備ツール。250 以上の変換(クレンジング・正規化)をGUI で適用し、レシピとして再利用できる。
- AWS Glue Studio
- Glue ETL ジョブを視覚的なノードグラフで作成・実行・監視するオーサリング環境。生成された Spark コードを編集することもできる。
- AWS Graviton(ARM インスタンス)
- AWS 設計の ARM ベースプロセッサ。同等性能で x86 より低価格・高い電力効率(コスト最適化と持続可能性に寄与)。対応ワークロード(多くの Linux・コンテナ・マネージドサービス)で移行すると価格性能比が向上する。
- AWS Health Dashboard
- AWSサービスの稼働状況と、自分のリソースへの影響イベントを通知する(AWS側の状態。Trusted Advisorは自分の環境向けで別物)。
- AWS Health(Personal Health Dashboard)
- 自分のアカウントに影響するイベント(メンテナンス・障害・廃止予定)を通知するサービス。現在は AWS Health Dashboard(旧 Personal Health Dashboard)の「Your account health」が該当し、全体状況は「Service health」(旧 Service Health Dashboard)が示す。
- AWS Health(イベント/組織ビュー)
- 自分のリソースに影響する AWS 側のイベント(メンテナンス・障害・予定変更・証明書失効など)を通知するサービス。Health API/EventBridge で自動対応に連携し、Organizational View で全アカウントを一元把握する。
- AWS HealthLake
- 医療データ(FHIR 形式)を保存・変換・分析するためのマネージドなヘルスデータレイク。NLP で非構造の医療テキストから情報を抽出する。
- AWS IAM
- ID とアクセス管理。ユーザー/グループ/ロール/ポリシーで「誰が何をできるか」を最小権限で制御。ロールは一時権限(キー不要)。
- AWS IoT サービス群(Core / Greengrass 他)
- IoT のマネージドサービス群。IoT Core=デバイス接続/メッセージング、Greengrass=エッジ実行、Device Defender=セキュリティ監査、Device Management=大規模管理、IoT Events=イベント検知、SiteWise=産業データ収集(Things Graph・1-Click・IoT Analytics は提供終了済み)。
- AWS KMS
- 暗号鍵(KMS key。旧称 CMK/カスタマーマスターキー)の作成・管理・ローテーションを行うマネージドサービス。S3・EBS 等のデータを暗号化し、鍵の使用を IAM と鍵ポリシーで制御・CloudTrail で監査する。KMS key には AWS 管理と顧客管理(customer managed key)などの種類があり、両者は同義ではない。
- AWS Lake Formation
- データレイクの権限を一元管理するサービス。Glue データカタログのテーブルに列/行/セルレベルの細かなアクセス権を付与し、Athena/Redshift Spectrum/EMR からのアクセスに一貫適用。LF-Tags(タグベースアクセス制御)で属性により大規模にガバナンスできる。IAM だけでは難しい粒度を補う。
- AWS Lambda
- サーバーレス(FaaS)。イベント駆動で関数を実行し、実行した分だけ課金。サーバー管理が不要。
- AWS License Manager
- ソフトウェアライセンス(BYOL:持ち込みライセンス)を一元管理するサービス。ライセンス規則を定義して上限超過を防ぎ、専有ホストやコア/ソケット数に基づく利用を追跡・レポートする。組織横断のライセンスコンプライアンスに使う。
- AWS Marketplace
- サードパーティ製ソフトを見つけて調達できるカタログ(課金はAWS請求に統合)。
- AWS Migration Hub
- 移行プロジェクトの進捗をアプリ単位で一元管理するサービス。複数の移行ツールの状況を集約し、評価から完了まで俯瞰する。
- AWS Network Firewall
- VPC のトラフィックをステートフルに検査・フィルタリングするマネージドなネットワークファイアウォール。ドメイン許可リスト、IPS/IDS、プロトコル検査などで、SG/NACL より高度な境界防御を提供する。
- AWS Nitro System
- 専用ハードウェア(Nitro カード/セキュリティチップ)と軽量ハイパーバイザーで仮想化オーバーヘッドを最小化する EC2 の基盤。高い性能・セキュリティ(Nitro Enclaves による機密分離)・新インスタンスの土台になる。
- AWS OpsWorks
- Chef/Puppet でサーバー構成(パッケージ・サービス・デプロイ)をコード化したマネージド構成管理サービス。2024年5月26日に全スタックのサポートが終了済みで、移行先は Systems Manager(State Manager 等)や IaC。
- AWS Organizations(一括請求)
- 複数アカウントを束ね、一括請求でボリューム割引や管理の一元化、SCPで組織的なガードレールを実現する。
- AWS Pricing Calculator
- 構築前に想定構成のコストを見積もるツール。インスタンスタイプ・ストレージ・データ転送等を入力して月額概算を算出し、構成比較や提案に使う。
- AWS Private Certificate Authority
- 組織内で使うプライベート認証局(CA)をマネージドに運用できるサービス。ACM が扱えないプライベート証明書を発行し、内部サービス間の相互 TLS(mTLS)や IoT デバイス認証など、パブリック CA を使わない用途で階層 CA を構築できる。
- AWS PrivateLink
- インターネットを経由せず、VPC から AWS サービスや他アカウントのサービスへプライベート接続する仕組み。トラフィックが AWS ネットワーク内に留まり、公開経路を使わない。
- AWS Proton
- コンテナ/サーバーレスのデプロイをテンプレート化する内部開発者プラットフォーム。2024年末に新規顧客への提供を終了・非推奨化(既存のみ)。標準化は ECS Service Connect や自前の IaC テンプレート・Service Catalog 等で代替する。
- AWS Resilience Hub
- アプリケーションのレジリエンス(回復力)を評価・追跡するサービス。RTO/RPO の目標を定義し、構成を分析して目標とのギャップや単一障害点を洗い出し、改善の推奨と継続的な評価を提供する。DR/可用性設計の検証に使う。
- AWS Resource Explorer
- リージョン横断でリソースを検索・発見するサービス。既定は単一アカウント内の検索で、組織全体の横断検索はマルチアカウント検索の設定が必要。タグや種別で素早く探せ、棚卸しに使う。Resource Groups(グループ化)に対し検索が主眼。
- AWS Resource Groups
- タグやリソースの種類、CloudFormation スタックなどの条件でリソースをまとめ、1つの論理的なグループとして扱う機能。グループ化した後は Systems Manager の Automation・Patch Manager や監視ダッシュボードの対象範囲として一括操作できる。
- AWS SAM(Serverless Application Model)
- サーバーレス(Lambda/API Gateway/DynamoDB 等)向けに CloudFormation を簡潔に書ける拡張。短い構文がデプロイ時に CloudFormation テンプレートへ展開される。sam local でローカル実行・テストも可能。
- AWS SDK とツール
- 各言語(Python=boto3、JavaScript、Java、Go など)から AWS API を呼ぶための公式ライブラリ群。認証情報の解決・自動リトライ(指数バックオフ)・ページネーション・リージョン設定を共通仕様で扱い、アプリや Lambda から AWS を操作する基盤になる。
- AWS Secrets Manager
- DB 認証情報や API キーなどのシークレットを安全に保管し、Lambda で自動ローテーションできるサービス。SSM Parameter Store より高機能(ローテーション・クロスアカウント共有)で、利用に応じ課金。
- AWS Security Hub
- GuardDuty・Inspector・Macie・Config などの検出結果を ASFF 形式で一元集約し、CIS や AWS 基礎セキュリティ標準に対する準拠スコアを提示するサービス。組織のセキュリティ態勢を可視化する。
- AWS Serverless Application Repository (SAR)
- SAM で定義済みのサーバーレスアプリを検索・デプロイ・公開できるリポジトリ。再利用可能なアプリ/コンポーネント(関数・API・連携部品)を組織内外で共有し、ワンクリックに近い形で展開できる。
- AWS Service Catalog
- 承認済みの IT サービス(CloudFormation 製品)をポートフォリオとして公開し、利用者がセルフサービスで標準構成をデプロイできるようにする。ガードレール付きで統制とスピードを両立する。
- AWS Shield Advanced
- 大規模 DDoS 攻撃に対する高度な保護。常時検知・DDoS 対応チーム(DRT/SRT)支援・コスト保護・WAF 連携を提供する(標準の Shield Standard は無料で基本保護)。
- AWS Shield(Standard/Advanced)
- DDoS 防御サービス。Standard は全 AWS で無料・自動の L3/L4 防御。Advanced は有償で、L7 防御・24/7 の DRT 支援・コスト保護・詳細レポートを追加する。WAF と組み合わせる。
- AWS Site-to-Site VPN
- オンプレミスと VPC を IPsec で暗号化接続する VPN。インターネット経由で迅速・安価に構築でき、各接続は冗長な2トンネル。Direct Connect より帯域は劣るが、そのバックアップにも使う。
- AWS Snow Family
- 回線が細い・期限が厳しい・大容量データを、暗号化された物理デバイス(Snowball Edge)で AWS へオフライン輸送するサービス。ネットワーク転送が現実的でない場合に使う(ペタバイト級トラックの Snowmobile は提供終了済み)。
- AWS Step Functions
- 複数ステップのワークフローをステートマシンとして編成するサービス。分岐・並列・リトライ・エラー処理・待機を宣言的に記述し、Lambda 等を順序立てて実行する。
- AWS Storage Gateway
- オンプレからクラウドストレージへハイブリッド接続するゲートウェイ。File Gateway(NFS/SMB→S3)、Volume Gateway(iSCSI)、Tape Gateway(仮想テープ→Glacier)がある。
- AWS STS
- 一時的な認証情報を発行するサービス(Security Token Service)。AssumeRole やフェデレーションのリクエストを受け、短命の認証情報を返す。長期キーの配布を避ける中核。
- AWS Systems Manager(SSM)
- インスタンス群を SSH/RDP を開けずに大規模運用する統合ツール。Run Command(一括コマンド)・Session Manager(ポート開放不要のシェル)・Patch Manager(パッチベースライン+メンテナンスウィンドウ)・Automation(ランブックで自動修復)・Parameter Store(設定/SecureString)。利用には SSM エージェントと IAM ロールが必要。
- AWS Transfer Family
- SFTP/FTPS/FTP を用いて外部パートナーと S3/EFS との間でファイルを継続的に授受するマネージドサービス。既存の転送プロトコルを保ったままバックエンドをクラウド化できる。
- AWS Transform
- 生成 AI(エージェント)でレガシーワークロード(.NET 移行・メインフレーム・VMware 等)のモダナイゼーション/移行を加速するサービス。
- AWS Trusted Advisor
- コスト・セキュリティ・耐障害性・パフォーマンス・サービス制限の観点でベストプラクティスを点検・推奨する(自分の環境向け)。
- AWS User Notifications
- 複数のソース(CloudWatch アラーム・Health・Security Hub の検出結果など)からの AWS 通知を一元的に設定・集約し、コンソールやメール等へ配信するサービス。セキュリティイベントの可視化・到達性を高める。
- AWS Verified Access
- VPN なしで企業内アプリへ安全にアクセスさせるゼロトラストのサービス。リクエストごとに ID プロバイダーやデバイスの信頼シグナル(ポリシー)を評価して許可し、アクセスのたびに検証する。
- AWS WAF
- Web アプリケーションファイアウォール。SQL インジェクションやクロスサイトスクリプティング等の不正な HTTP リクエストを、マネージドルールやレート制限で検査・ブロックする。CloudFront・ALB・API Gateway に適用。
- AWS Well-Architected フレームワーク
- クラウド設計のベストプラクティス集。6本の柱(運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性)で点検する。
- AWS X-Ray
- 分散トレース。1リクエストが通る各サービスの区間(セグメント/サブセグメント)と遅延を記録し、サービスマップでボトルネックやエラーを特定する。サンプリングで一部を記録。ログ(何が起きたか)を補完。
- AWS サポートプラン
- Basic<Developer<Business<Enterprise On-Ramp<Enterprise の 5 階層。24×7 技術サポートは Business 以上、専任 TAM は Enterprise、Enterprise On-Ramp はプール制の TAM。
- AWS パートナーとサポートリソース
- AWS Partner Network(APN)の認定パートナー、AWS Professional Services、AWS Marketplace、ナレッジセンター/re:Post など、導入・運用を支援するリソース群。
- AWS マネジメントコンソール
- AWS リソースを GUI で操作・監視する Web コンソール。CLI/SDK/IaC と並ぶ主要な操作手段。
- AWS(Amazon Web Services)
- 世界最大級のパブリッククラウド。コンピュート・ストレージ・DB・ネットワーク等を従量課金で提供する。
- AzCopy
- Blob/ファイル共有との間で大量データを高速にコピー・アップロード・ダウンロードする コマンドライン ツール。並列転送やチェックポイント再開に対応し、GUI の Storage Explorer よりスクリプト化・自動化に向く。認証は Microsoft Entra ID または SAS トークン。
- Azure Advisor
- 自分のリソースに対するコスト・セキュリティ・信頼性・性能・運用の推奨を提示する。
- Azure AI Content Safety
- 有害・不適切なコンテンツを検出・抑制するコンテンツフィルター。生成AIの安全運用に使う。
- Azure AI Document Intelligence
- 請求書・レシート・フォームから項目(金額・日付等)を構造化抽出する(ドキュメントインテリジェンス)。
- Azure AI Language
- 感情分析・エンティティ認識・キーフレーズ抽出・言語検出・要約・会話言語理解(CLU)など、テキスト理解を担う。
- Azure AI Search(ナレッジマイニング)
- 大量の文書を索引化して横断検索可能にする(ナレッジマイニング)。RAGの検索基盤にも使う。
- Azure AI services
- 事前構築の AI 機能を API で提供するサービス群(旧 Cognitive Services)。キー+エンドポイントで利用。
- Azure AI Speech
- 音声⇔テキスト(音声認識・読み上げTTS)と音声翻訳を担う。
- Azure AI Translator
- テキストの言語間翻訳を担うサービス。
- Azure AI Video Indexer
- 動画やライブ配信から話者・文字起こし・顔・ラベル・感情などの insight を抽出するサービス。
- Azure AI Vision
- 画像のタグ・キャプション・物体検出・OCR(Read)など汎用的なコンピュータービジョンを事前構築モデルで提供。
- Azure API Management(APIM)
- 複数のバックエンド API を統一された入口で公開する API ゲートウェイ。ポリシー(XML・インバウンド/バックエンド/アウトバウンド/エラー)で認証(validate-jwt)・レート制限・変換・キャッシュ・CORS を適用。製品とサブスクリプション(キー)で利用者へ提供、開発者ポータルでドキュメント提供、バックエンド認証はマネージド ID、シークレットは名前付き値(Key Vault)。
- Azure App Configuration
- アプリ設定や機能フラグを一元管理するサービス。設定を集中管理し、機密は Key Vault 参照で安全に扱う。機能フラグで段階的リリースができる。
- Azure App Service
- Web アプリや API を PaaS で手早くホストするサービス。OS管理不要でスケールも容易。
- Azure Arc
- オンプレミスや他クラウドのサーバー・Kubernetes・DBを、Azureの管理面(ポリシー/タグ/RBAC)で一元管理する。
- Azure Arc 対応 SQL
- オンプレや他クラウドの SQL Server を Azure Arc で Azure に接続し、インベントリ・評価・更新・Defender/Purview 等を一元管理する仕組み。
- Azure Artifacts
- 依存パッケージ(npm/NuGet/Maven/Python)をフィードで一元管理するサービス。上流ソース(公開リポジトリ)をプロキシ・キャッシュし、社内パッケージと公開パッケージを 1 つのエンドポイントに統合する。
- Azure Automation(Runbook)
- PowerShell/Python の Runbook でクラウド/オンプレ横断の運用を自動化するサービス。ハイブリッドワーカーでオンプレ実行もできる。
- Azure Backup
- VM・ファイル共有・SQL/SAP HANA 等を定期的にバックアップし、Recovery Services コンテナーへ保存するマネージドサービス。必要なときに任意の復元ポイントからリストアする「データ復元」が目的で、暗号化・保持ポリシー・即時リストアに対応する。
- Azure Backup for SAP HANA
- SAP HANA データベースを DB 整合のストリームバックアップで保護する Azure Backup の機能。VM バックアップだけでは DB 整合が保証されないため、HANA の保護に用いる。
- Azure Bastion
- VM に公開 IP を付けずに、ブラウザ越し(Azure ポータル)で RDP/SSH 接続できるマネージドな踏み台サービス。管理ポートをインターネットに開放せずに済み、攻撃面を減らす。必要時のみ管理ポートを一時開放する Just-In-Time VM アクセスと併用されることが多い。
- Azure Blob Storage コネクタ
- Azure のオブジェクトストレージ(Blob)にファイルを読み書きするコネクタ。大きなファイルの保存先として使う。プレミアム。
- Azure Boards
- アジャイルな作業管理サービス。作業項目をエピック→フィーチャー→ストーリー/PBI→タスクの階層で分解し、バックログで優先順位付け、スプリント(イテレーション)で計画、かんばんボードで状態を可視化し WIP を制限する。作業項目をコミット/PR/ビルドにリンクしてトレーサビリティを確保する。
- Azure Cache for Redis
- 高速なインメモリキャッシュ。読み取り負荷軽減やセッション保存に使い TTL で鮮度を管理する。旧 Azure Cache for Redis は退役予定で、後継は Azure Managed Redis。
- Azure CDN
- 静的コンテンツをエッジにキャッシュし低遅延で配信する。Microsoft 標準プロファイルが現行で、旧 Verizon/Edgio プロファイルは廃止方向。新規は Azure Front Door(CDN 統合)が推奨。更新はパージで反映。
- Azure Center for SAP solutions(VIS)
- SAP システムを仮想インスタンス(Virtual Instance for SAP solutions, VIS)として Azure に表現し、展開・start/stop・統合管理を Azure 起点で行うサービス。SAP 起点で Azure を操作する LaMa コネクタとは方向が逆。
- Azure Cloud Shell
- ブラウザ内のターミナル(Azure CLI と PowerShell 入り・セットアップ不要・認証済み)。
- Azure Compute Gallery
- カスタムイメージをバージョン管理し、複数リージョンへレプリケーションして多数の VM/サブスクリプションへ大規模配布するサービス(旧 Shared Image Gallery)。Azure Virtual Desktop ではセッションホストイメージの版管理とスケール配布に使う。
- Azure Container Apps
- Kubernetes を意識せずコンテナ/マイクロサービスを動かすサーバーレス基盤。KEDA でイベント駆動スケール(ゼロスケール可)、Dapr 連携に対応。
- Azure Container Instances(ACI)
- オーケストレーション不要で単発・手軽にコンテナを動かすサービス。
- Azure Content Understanding
- ドキュメント・画像・動画・音声から、要約・分類・属性検出・エンティティ/表/画像抽出をマルチモーダルに行う情報抽出サービス。
- Azure Cosmos DB
- グローバル分散・低遅延・自動スケールのマネージド NoSQL。複数 API(NoSQL/MongoDB/Cassandra/Gremlin/Table)対応。
- Azure Cosmos DB for NoSQL
- JSON ドキュメントを格納するグローバル分散の非リレーショナルデータベースサービス(旧 SQL API)。アクセスパターン起点でモデルを設計し、SQL ライクなクエリでドキュメントを操作する。Cosmos DB は MongoDB/Cassandra/Table/Gremlin 用の API も提供する。
- Azure Data Box
- ネットワーク転送が非現実的な大容量データを、物理ストレージデバイスを介してオフラインで Azure へ取り込む/持ち出すサービス。旧来のオフライン転送だった Azure Import/Export は 2024 年 11 月以降新規受付を終了しており、現行はこの Data Box(容量別に複数モデルあり)が後継。
- Azure Data Factory
- データの取り込み・変換・オーケストレーションを行う ETL/ELT パイプラインサービス。
- Azure Data Lake Storage Gen2
- Blob ストレージ上に階層型名前空間を追加した、大規模分析向けのデータレイク。ディレクトリ構造と POSIX 風の ACL を持ち、Synapse や Databricks の分析基盤の蓄積層として使われる。
- Azure Database for MySQL
- OSS の MySQL エンジンをマネージドで提供するリレーショナルサービス。現行は Flexible Server 形態で、同一可用性ゾーン内配置によるレイテンシ最適化や柔軟なコンピュート/ストレージのスケーリングに対応する。パッチ適用・バックアップ・フェイルオーバーは Azure が運用する。
- Azure Database for PostgreSQL
- OSS の PostgreSQL エンジンをマネージドで提供するリレーショナルサービス。現行は Flexible Server 形態で、可用性ゾーン配置やバーストキャパブル SKU、きめ細かなメンテナンスウィンドウ設定に対応する。パッチ適用・バックアップ・フェイルオーバーは Azure が運用する。
- Azure Database Migration Service(DMS)
- データベースを Azure SQL へ移行するマネージドサービス。Azure SQL Migration 拡張機能と連携し、オンライン/オフライン移行を実行する。
- Azure Databricks
- Apache Spark に最適化された大規模データ処理・機械学習の基盤。データサイエンス用途に強い。
- Azure DDoS Protection
- 大量のトラフィックでサービスを停止させる DDoS 攻撃を検知・吸収し、可用性を守る。
- Azure DNS Private Resolver
- オンプレと Azure 間の DNS 解決を仲介するマネージドサービス。条件付きフォワーダーで特定ドメインの問い合わせを適切な DNS へ転送する。
- Azure DNS(パブリックゾーン)
- ドメインの公開 DNS レコードを Azure でホストするサービス。インターネットからの名前解決を提供する。
- Azure Event Grid
- 離散イベント(「Blob 作成」等)をリアクティブに配信する pub/sub。イベントサブスクリプションで購読し、ほぼリアルタイムに反応する。
- Azure Event Hubs
- 大量のストリーミング/テレメトリを取り込む高スループットのイベント取り込み。パーティションとコンシューマーグループで並列に処理する。
- Azure File Sync
- オンプレの Windows ファイルサーバーを Azure Files と同期するサービス。クラウド階層化でアクセス頻度の低いファイルをクラウドへ移し、ローカル容量を節約する。
- Azure Files(File ストレージ)
- SMB/NFS のファイル共有。複数のマシンから同時にマウントできる。
- Azure Firewall
- マネージドでステートフルなネットワークファイアウォール。中央で通信を制御する。
- Azure Firewall の規則
- Azure Firewall の 3 種類の規則。DNAT 規則=受信を内部へ変換転送、ネットワーク規則=IP/ポート/プロトコルの L3-L4 制御、アプリケーション規則=FQDN ベースの L7 制御。
- Azure Front Door
- グローバルな L7 のエントリポイント。CDN キャッシュ・グローバルルーティング・WAF・SSL オフロードを兼ね、可用性と性能を高める。
- Azure Functions
- サーバーレス(FaaS)の代表。イベント駆動で関数を実行し、実行分だけ課金。
- Azure IoT Hub(Cosmos DB 連携)
- IoT デバイスのテレメトリを集約するサービス。カスタムエンドポイントを構成して Cosmos DB へデータを流すデータ移動経路の一つになる。
- Azure Key Vault
- 鍵・シークレット・証明書を安全に保管・管理するサービス。アプリに直接埋め込まずに済む。
- Azure Kubernetes Service(AKS)
- マネージドな Kubernetes。多数のコンテナの本番オーケストレーション(自動配置・自己修復・スケール)。
- Azure Load Balancer
- L4(TCP/UDP)でトラフィックを分散するリージョン内の高速ロードバランサー。公開/内部、ヘルスプローブ、バックエンドプールを構成する。
- Azure Logic Apps
- 多数のコネクタを使ってワークフローをノーコード/ローコードで統合するサービス。SaaS やオンプレ、Azure サービスをトリガー/アクションでつなぎ、業務プロセスの自動化やシステム間連携を実現する。
- Azure Machine Configuration
- 旧ゲスト構成。ゲスト OS の構成設定をコード化して監査・適用し、構成ドリフトを強制的に是正する。
- Azure Machine Learning
- MLのワークフロー(準備→学習→評価→デプロイ→予測)を支援。Automated ML(自動最良選択)とDesigner(ノーコード)がある。
- Azure ML のコンピューティングとデータ(ワークスペース/クラスター/データアセット)
- Azure ML ワークスペースが ML の成果物(データ・モデル・実験・エンドポイント)を一元管理し、関連リソース(ストレージ/Key Vault/Application Insights/Container Registry)が紐づく。コンピューティングは開発用のコンピューティングインスタンス(個人・停止でコスト節約)と学習をスケールさせるコンピューティングクラスター(オートスケール・アイドル時 0 ノード・低優先度/Spot VM 可)。データは Blob/ADLS への接続情報=データストアと、再利用可能・バージョン管理された参照=データアセット(uri_file/uri_folder/mltable)。学習済みモデルはモデルレジストリでバージョン管理。環境(conda/Docker)で依存を固定し再現性を担保。操作は Studio/Python SDK v2/CLI v2。
- Azure ML のジョブと AutoML/スイープ(MLflow・ハイパーパラメーター調整)
- 学習はジョブとして実行:コマンドジョブ(単一スクリプト)・スイープジョブ(ハイパーパラメーター探索)・パイプラインジョブ(コンポーネントの DAG)。定義は YAML(CLI v2)/SDK v2。トラッキングは MLflow がネイティブ統合(log_metric/log_param/log_artifact・autolog)で実験を比較。AutoML はタスク指定でアルゴリズム/前処理を自動探索しリーダーボードで選択。スイープは探索空間+サンプリング(グリッド/ランダム/ベイズ)+早期終了(Bandit/中央値停止)でハイパーパラメーターを調整、max_concurrent_trials で並列度とコストを制御。
- Azure ML のデプロイ(オンライン/バッチエンドポイント・トラフィック分割)
- 推論はエンドポイントで提供。マネージドオンラインエンドポイント=リアルタイム低遅延(Azure がインフラ管理・オートスケール)/Kubernetes オンライン=既存 AKS/バッチエンドポイント=大量データをコンピューティングクラスター上で非同期スコアリング。1 エンドポイントに複数デプロイを置き、トラフィック分割でブルー/グリーン(段階的ロールアウト・即ロールバック)。デプロイにはスコアリングスクリプト(init/run)と環境、適切なインスタンス種別/数が必要(MLflow モデルは推論コード不要なことも)。アクセスはマネージド ID+キー/トークン認証、必要ならプライベートエンドポイント。
- Azure ML ワークスペース
- ML の成果物(データ・モデル・実験・エンドポイント)を一元管理する最上位リソース。ストレージ・Key Vault・Application Insights・Container Registry が紐づく。
- Azure Monitor
- リソースのメトリックとログを収集する監視の基盤。Log Analytics(KQL分析)やApplication Insights(アプリ監視)、アラートにつながる。
- Azure Monitor Agent(AMA)
- ログ収集の標準エージェント(旧 MMA/Log Analytics エージェントの後継)。収集対象はデータ収集規則(DCR)で宣言的に定義する。Windows セキュリティイベントは Windows Security Events via AMA、構造化機器ログは CEF via AMA、一般 Syslog は Syslog via AMA で取り込む。
- Azure Monitor for SAP solutions(AMS)
- SAP HANA・NetWeaver・OS・高可用性クラスタなどの SAP 固有の内部メトリクスを(プロバイダー経由で)Azure Monitor ワークスペースに取り込み、統合監視/アラートする専用ソリューション。汎用 Azure Monitor(インフラ)と区別する。
- Azure NAT Gateway
- サブネットからの送信(アウトバウンド)専用の NAT。SNAT ポート枯渇を避けて安定した外向き接続を提供する(受信は提供しない)。
- Azure NetApp Files
- 高性能・低遅延で大規模に使えるマネージドの NFS/SMB ファイルストレージ。Azure Virtual Desktop では大規模環境の FSLogix プロファイルなど高 IOPS が必須の用途に選ぶ。中小規模でコスト効率を優先する場合は Azure Files Premium を選ぶ。
- Azure OpenAI Service
- GPT等の基盤モデルにAzure経由で安全にアクセスし、自分のアプリに生成AIを組み込む(企業向け統制)。
- Azure OpenAI モデルデプロイと PTU
- Azure OpenAI でモデルを選んでデプロイし、エンドポイントとして公開する。スループットは従量課金か、確保されたプロビジョニング済みスループット(PTU)で安定させる。
- Azure Pipelines
- CI/CD をコード(YAML)で定義するパイプラインサービス。ステージ→ジョブ→ステップの階層で構成し、push/PR/スケジュールのトリガーで起動、テンプレートで再利用する。実行は Microsoft ホスト/セルフホストのエージェントで行う。
- Azure Policy
- リソースが満たすべき条件(許可リージョン・必須タグ等)をルールとして定義・強制し、準拠状況を評価する。
- Azure Pricing Calculator
- これから構築する Azure 構成の月額コストを見積もる Web ツール。リージョン・SKU・使用時間・データ転送量などを入力してサービスごとの概算料金を算出し、構成案の比較や提案書作成に使う。実際の請求とは為替・実利用量の差で乖離しうる。
- Azure Private Link / Private Link Service
- PaaS や自作サービスへの接続を VNet 内のプライベート IP に閉じる基盤。Private Link はプライベートエンドポイント(プライベート IP を持つ NIC)を通じて PaaS(Storage/SQL 等)へ公開経路を使わず接続する。PaaS の公開 FQDN は CNAME で privatelink ゾーンを指し、プライベート DNS ゾーンの A レコードがプライベート IP に解決する(連携忘れで公開 IP に解決=事故)。サブリソース(blob/file 等)ごとにエンドポイントとゾーンが必要。オンプレ解決は DNS プライベートリゾルバ+条件付きフォワーダー。Private Link Service は自作サービス(背後に Standard Load Balancer)を Private Link で他テナント/VNet に提供する。サービスエンドポイントと異なり実際のプライベート IP を付与しオンプレからも到達できる。
- Azure Resource Manager(ARM)
- リソースの作成・変更・削除を受け付ける統一管理レイヤー。portal/CLI/PowerShell/テンプレートの全要求が通る。
- Azure Route Server
- NVA と Azure の間で BGP により経路を自動交換させるマネージドサービス。UDR の手動更新なしに NVA の経路を VNet に反映できる。
- Azure Service Bus
- エンタープライズ向けのメッセージブローカー。順序・トランザクション・重複排除・デッドレターに対応し、確実な指示(コマンド)の配送に使う。
- Azure Service Health
- Azure 自体の障害・計画メンテナンス・正常性を通知する(Advisorは自分のリソースへの助言で別物)。
- Azure Site Recovery(ASR)
- VM を別リージョン(または オンプレ⇔Azure)へ継続的にレプリケートし、災害時にフェイルオーバーして稼働を継続させる DR(災害復旧)サービス。テストフェイルオーバーで本番を止めずに手順検証でき、復旧計画(Recovery Plan)で複数 VM の起動順序をオーケストレーションする。
- Azure SQL Database
- フルマネージドなリレーショナル PaaS。パッチ・バックアップ・可用性を Azure が担う。新規クラウドアプリ向け。
- Azure SQL Database in Fabric
- Microsoft Fabric 内に統合された Azure SQL Database。OneLake へのミラーリングや Fabric の分析体験と密接に連携する運用形態。
- Azure SQL の Microsoft Entra 認証
- Azure SQL の推奨認証。Entra ID で一元管理し、MFA・条件付きアクセス・マネージド ID でのパスワードレス接続に対応する。Entra ID 管理者を構成して有効化する。
- Azure SQL の認証/アクセス制御・データ保護
- 認証は Microsoft Entra 認証(推奨・一元管理・MFA/条件付きアクセス・マネージドID でパスワードレス)と SQL 認証。ログイン(サーバー)とユーザー(DB)を区別し、SQL Database ではコンテインドユーザーが推奨。認可は固定/カスタムロールと GRANT/DENY/REVOKE(DENY 優先)で最小権限。行は行レベルセキュリティ(RLS)、列は列レベル権限で絞る。データ保護は動的データマスク(表示の制限・UNMASK で実値)と監査(操作を Log Analytics/Storage に記録)。暗号化は TDE/Always Encrypted(別項)。
- Azure Storage Explorer
- Blob・ファイル共有・キュー・テーブルを GUI で閲覧・アップロード・管理できるスタンドアロンアプリ(Windows/macOS/Linux)。少量データの確認や手動操作、アクセス許可の簡易設定に向き、大量データの高速転送は AzCopy を使う。
- Azure Stream Analytics
- 到着し続けるストリーミングデータをほぼリアルタイムで処理するサービス。
- Azure Synapse Analytics
- 大規模なデータウェアハウジングと統合分析(SQL・Spark・パイプライン)を1つにまとめたプラットフォーム。機能は次世代の Microsoft Fabric に統合・継承が進み、新規ワークロードは Fabric が推奨。
- Azure Synapse Link
- Cosmos DB の分析ストアに対し、Azure Synapse の Spark/SQL から直接クエリできるようにする統合機能。トランザクションストア(運用)に影響を与えずに分析(HTAP)を行う。分析ストアの有効化が前提。
- Azure Test Plans と自動テスト
- Azure Test Plans で手動/探索テストを管理し、パイプラインに単体・統合・UI テストを組み込んで品質ゲートとし、結果とコードカバレッジを可視化する。負荷テストは別サービスの Azure Load Testing を利用する。
- Azure Traffic Manager
- DNS ベースのグローバルなトラフィック振り分け。優先度/重み付け/パフォーマンス/地理的などのルーティング方式で応答する IP を返す(実通信は直接バックエンドへ)。
- Azure Virtual Machines(VM)
- IaaSの仮想マシン。OSから上を自分で管理する最も自由度の高いコンピュート。
- Azure Virtual Network Manager
- 多数の VNet をネットワークグループとして束ね、接続構成とセキュリティ管理者規則を一元適用する。セキュリティ管理者規則は NSG より先に評価される高位規則で、各チームが NSG で上書きできない組織全体のガードレールを強制する。
- Azure Virtual Network Manager
- 多数の VNet の接続(メッシュ/ハブ&スポーク)とセキュリティ規則を一元管理するサービス。ネットワークグループ単位で構成を一括適用する。
- Azure Virtual WAN
- 多数の拠点・VNet・リモートユーザーをマネージドなハブ(Microsoft バックボーン上)で一元管理する大規模ネットワークサービス。VPN・ExpressRoute・VNet 接続を集約し、ハブが中継するためスポーク間も非推移の問題なく到達できる。SKU は Basic(S2S VPN のみ)と Standard(ExpressRoute/P2S/ハブ間/Secured Hub などフル機能)。Secured Virtual Hub はハブに Azure Firewall を組み込み、Firewall Manager で複数ハブのポリシーを一元適用して集中検査する。小規模は手組みハブ&スポーク、大規模・グローバルは Virtual WAN。
- Azure VM extension for SAP solutions
- SAP VM にインフラ構成/監視データを SAP へ提供する拡張機能。Azure 上の SAP をサポート対象にするため実質必須で、デプロイ後に構成する。
- Azure VM Image Builder
- テンプレートでイメージのビルドを宣言的に定義し、カスタマイズ手順を自動実行してセッションホストイメージを再現可能にビルドするサービス。手動の Sysprep ベース作成より一貫性が高い。生成したイメージは Azure Compute Gallery で配布する。
- Azure Well-Architected Framework
- ワークロード設計を評価する 5 つの柱=信頼性・セキュリティ・コスト最適化・オペレーショナルエクセレンス・パフォーマンス効率。トレードオフを意識して設計判断を行う。
- Azure ストレージアカウント
- Blob・File・Table・Queue の各ストレージサービスをまとめて提供する入れ物。
- Azure のサポートプラン
- Basic(無料・課金/サブスク管理)、Developer(試用)、Standard(運用)、Professional Direct(ビジネスクリティカル)から選ぶ。応答時間とアーキテクチャ支援が異なる。
- Azure ポータルと Marketplace
- Azure portal は GUI でリソースを一元管理する Web コンソール。Azure Marketplace は Microsoft/サードパーティのソリューションを購入・デプロイできる。モバイルアプリでも監視/操作できる。
- Azure ランディングゾーン
- 管理グループ・サブスクリプション・ポリシー・ネットワーク・ID を含む、拡張可能で統制された Azure 環境の設計図。Cloud Adoption Framework のエンタープライズスケールに基づく。
- Azure ランディングゾーン(CAF)
- Cloud Adoption Framework のエンタープライズスケールに基づく、標準化された基盤の青写真。ネットワーク(ハブ&スポーク)・ID・ポリシー・管理を事前構成し、管理グループ階層に沿って一貫したガバナンスを展開できる。
- B2B direct connect
- 外部テナントのユーザーをゲストとして招待せず、双方のテナントが Cross-tenant access settings で互いを信頼し合うことで、shared channels(共有チャンネル)を通じた協業を可能にする接続方式。相手は自テナントの ID のままサインインでき、ゲストユーザーオブジェクトが作成されない点が B2B コラボレーションとの違い。
- B2B コラボレーション(Entra External ID)
- 取引先など外部組織のユーザーをゲストとして招待し、相手側の既存 ID のまま自社リソースへ共同アクセスさせる仕組み。現行は Microsoft Entra External ID に統合されており、条件付きアクセスやクロステナントアクセス設定で招待・権限を細かく制御する。招待されたゲストは自社(招待元)テナント内にゲストユーザーとして登録され、外部組織の資格情報で認証される(別テナントが作られるわけではない)。
- B2C(Azure AD B2C)
- 消費者向けアプリのサインアップ/サインインをカスタマイズできる CIAM(顧客 ID・アクセス管理)機能。ソーシャルログインやカスタムポリシーでブランド化したログイン体験を提供する。旧 Azure AD B2C は2025年5月以降に新規テナントを作成できず、Microsoft Entra External ID への統合・移行が進んでいる。
- BASE特性
- ACID特性と対比される、多くの NoSQL/分散システムが採用する設計思想。基本的に可用(Basically Available)・柔軟な状態(Soft state)・結果整合性(Eventually consistent)の略で、厳密な一貫性より可用性とスケーラビリティを優先する。
- Basic認証・APIキー・Bearerトークン
- API認証の代表的な3方式。Basic認証はユーザー名とパスワードをBase64エンコードしてヘッダに載せる簡易だが弱い方式。APIキーは発行された固定の鍵文字列をヘッダやクエリパラメータで送る方式。Bearerトークンは認証後に発行される一時的なトークン(OAuthのアクセストークン等)を「Authorization: Bearer」ヘッダで提示する方式で、有効期限を切れることでキー漏洩時の被害を抑えられる。
- BCDR 設計(バックアップ/災害復旧)
- 事業継続と災害復旧の設計。Azure Backup でデータを保護し、Azure Site Recovery でリージョン間レプリケーション/フェイルオーバー、ゾーン冗長やマルチリージョンで RPO/RTO 要件を満たす。
- BCM(事業継続マネジメント)
- BCPを策定するだけでなく、教育・訓練・演習を通じて実効性を検証し、経営環境の変化に合わせて継続的に見直す、組織的なマネジメント活動全体。BCPが「計画」であるのに対し、BCMはそれを回し続けるPDCAの枠組みを指す。
- BCP(事業継続計画)
- 地震やサイバー攻撃などの緊急事態が発生しても、中核となる事業を中断させない、または中断しても目標時間内に復旧させるための行動計画。優先して継続・復旧すべき業務の選定と、それを支えるIT資産の対応をあらかじめ定めておく。
- Bedrock agent tracing(推論トレース)
- エージェントの推論ステップを記録・可視化し、なぜその結論に至ったかを監査・デバッグ・透明性提示に使う機能。
- Bedrock Guardrails
- 生成 AI の入出力に安全策を適用する機能。拒否トピック・コンテンツフィルター・PII マスキング・コンテキストグラウンディングチェックで有害/不適切な応答を抑える。
- Bedrock Model Evaluations
- 複数のモデルやプロンプト構成を自動指標(正確性・毒性・堅牢性など)や人手評価で体系的に比較する Amazon Bedrock の機能。ユースケースに最適なモデルやパラメータを選定するために、本番投入前のベンチマークとして使う。
- Bedrock Model Invocation Logs
- Amazon Bedrock の各リクエスト/レスポンスを S3 や CloudWatch Logs に記録し、詳細な品質分析や監査に使えるログ機能。
- Bedrock ストリーミング(InvokeModelWithResponseStream)
- 生成トークンを逐次返すストリーミング API。全文完成を待たずに先頭から表示でき、体感レイテンシ(最初のトークンまでの時間=TTFT)を改善する。チャット UI や長い生成で UX を高める。
- Bedrock のデータプライバシー
- Bedrock では入力・出力を基盤モデルの学習に既定で使用せず、データはアカウント内に留まる。VPC エンドポイント(PrivateLink)でインターネットを経由せず接続し、KMS で暗号化、CloudTrail で監査できる。機密データを扱う生成 AI の前提。
- Bedrock のモデルカスタマイズ
- 基盤モデルを独自データで適応させる方法。ファインチューニング(ラベル付きデータ)と継続的事前学習(ラベルなし大量データ)があり、どちらもプライベートな専用モデルを作る。
- Bedrock の基盤モデル(プロバイダー)
- Amazon Bedrock は複数プロバイダーの基盤モデルを単一 API で提供する。Anthropic Claude・Amazon Titan/Nova・Meta Llama・Mistral・Cohere・Stability AI などをユースケースで選ぶ。
- Bedrock の推論モード(オンデマンド/プロビジョンド)
- オンデマンドは使った分だけ課金。プロビジョンドスループットは容量(モデルユニット)を確保し安定した大規模・低レイテンシ推論に対応する。カスタム/ファインチューニング済みモデルの推論は多くプロビジョンドスループットが前提(オンデマンド対応はモデル依存)。
- BeyondCorp
- ネットワークの場所ではなくユーザーとデバイスの検証に基づいてアクセスを許可する、Google のゼロトラスト実装。
- BFF(Backends for Frontends)
- Web・モバイルなどフロントエンドの種別ごとに専用のバックエンドを設け、その画面に最適な形へデータを集約・整形して返す設計パターン。各フロントの都合を専用層に閉じ込めるため、共通APIを画面ごとに肥大化させずに済み、通信回数や転送量も端末特性に合わせて最適化できる。API集約の責務をどこに置くかというアーキテクトの判断が問われる。
- BGP とルート伝播
- オンプレと Azure ゲートウェイ間で経路を動的に交換する標準プロトコル。自律システム番号(ASN)で相手を識別し、Azure ゲートウェイの既定 ASN は 65515、オンプレは自社 ASN を設定する。VPN で BGP を有効化すると拠点のサブネット増減が自動学習され UDR の手直しが不要に。ExpressRoute は常に BGP で経路交換(プライベート/Microsoft ピアリング)。学習経路を VNet に反映するのがルート伝播で、ルートテーブルで伝播を無効化すると UDR を確実に優先できる。同一宛先に複数経路があると ExpressRoute が VPN より優先される(バックアップ VPN 設計の根拠)。優先順位は最長プレフィックス一致→UDR>BGP>システム。
- BGP の経路制御(AWS)
- Direct Connect や VPN のハイブリッド経路を BGP の属性で制御する。AS-PATH プリペンドで特定経路の優先度を下げ、ローカルプリファレンスで送信側の優先を決め、BGP コミュニティでルート広告の範囲を制御する。
- BGP(経路属性による選択)
- AS(自律システム)間の経路制御に用いるパスベクタ型プロトコル。OSPFのコスト合計やRIPのホップ数ではなく、ローカルプリファレンス・AS_PATH長・オリジン・MEDなど複数の経路属性を優先順位に従って比較し、事業者間の契約やポリシーを反映した経路を選択する。
- BI Engine とマテリアライズドビュー
- BI Engine は BigQuery のインメモリ分析を高速化する。マテリアライズドビューはよく使う集計を事前計算しておく。ダッシュボードの応答を速くする別々の手段(併用可)。
- Bicep
- ARM テンプレート(JSON)をより簡潔に書ける DSL(ドメイン固有言語)。az bicep build でコンパイルすると等価な ARM テンプレート JSON に変換され、最終的にデプロイされるのは ARM テンプレートである。モジュール化やループ(loop)記法で可読性・再利用性が高い。
- BigLake
- Cloud Storage などのデータを移動せずに BigQuery から統一的に扱えるようにするストレージエンジン。レイクとウェアハウスを橋渡しする。
- BigQuery
- ペタバイト級のデータを SQL で高速に分析できる、Google Cloud のサーバーレスなデータウェアハウス。
- BigQuery Data Transfer Service
- SaaS や他のデータウェアハウスから BigQuery へデータを定期的に取り込むマネージドサービス。DB の移行は Database Migration Service と用途が異なる。
- BigQuery Editions と予約(reservations)
- 安定利用のコンピュート容量を予測可能なコストで確保する仕組み。少量・不定期はオンデマンドが向く。
- BigQuery ML
- BigQuery 上のデータに対し、データを移さず SQL だけで機械学習モデルを作成・予測できる機能。
- BigQuery ML のモデル種別
- データが BigQuery にあるとき SQL で学習/予測できるモデル群。分類/回帰、時系列予測の ARIMA_PLUS、レコメンドの行列分解、高精度な表形式のブーストツリー(XGBoost)、異常検知のオートエンコーダなどを課題で選ぶ。
- BigQuery へのログエクスポート
- 監査ログ/利用状況データを BigQuery に継続エクスポートし、SQL で横断分析・長期保管・カスタムレポート作成を行う。
- Bigtable
- IoT・時系列など超大量・低遅延のワークロード向けのワイドカラム型 NoSQL データベース。
- BLE(Bluetooth Low Energy)
- 通常のBluetoothに比べ消費電力を大幅に抑えた無線通信規格。常時接続ではなく必要な時のみ短時間通信し大半をスリープ状態で過ごすことで、コイン電池で年単位の駆動を実現できる。データレートは低いため、ウェアラブル機器やセンサなど間欠的に小容量データを送るIoT用途に適する。
- Blob ストレージ
- 画像・動画・バックアップなど非構造化データ(オブジェクト)向けのストレージサービス。
- Blob の SDK 操作
- BlobServiceClient/ContainerClient/BlobClient でコンテナーや BLOB を作成・アップロード・ダウンロード・列挙する開発操作。
- Blob のアクセス層
- アクセス頻度に応じたコスト最適化の層。ホット(高頻度)/クール(低頻度)/コールド/アーカイブ(ほぼ参照なし・取り出しに時間)。
- Blob のプロパティとメタデータ
- BLOB に付随するシステムプロパティ(Content-Type 等)と、ユーザー定義のキー/値メタデータの設定・取得。
- Blob のライフサイクル管理
- 一定日数で自動的にアクセス層を移動(ホット→クール→アーカイブ)したり削除したりするポリシー。保管コストを最適化する。
- Blob の保護(論理削除・バージョン管理・オブジェクトレプリケーション)
- Blob/コンテナーの論理削除で誤削除から復元、バージョン管理で履歴を保持、オブジェクトレプリケーションで別アカウントへ非同期コピーする。
- BLOB バージョン管理
- 上書き・削除のたびに以前の版を自動保持し、誤操作からの復元を可能にする Blob ストレージの保護機能。論理削除や不変ストレージと組み合わせて使う。
- BNF(バッカス・ナウア記法)
- プログラミング言語などの文法を再帰的な規則(生成規則)で厳密に定義するための記法。「::=」で左辺を右辺の候補列に置き換える形で構文規則を表す。
- BPDU Guard
- PortFastを設定したポートでBPDU(STPの制御フレーム)を受信した場合に、そのポートを即座にerr-disable状態にして遮断するCisco機能。末端ホスト専用のはずのポートにスイッチが誤接続・不正接続された場合の、意図しないトポロジ変化やループを防ぐ。
- BPM(ビジネスプロセスマネジメント)
- 業務プロセスを可視化・分析し、継続的に測定・改善するマネジメント手法。BPR(業務プロセス改革)が一度きりの抜本的な作り直しを指すのに対し、BPMはPDCAサイクルを回しながら継続的に業務プロセスの効率と品質を高めていく点が特徴。ITストラテジストはBPMツールでプロセスの実行状況を可視化し、経営目標に沿った継続的な業務改善の仕組みを事業戦略に組み込む。
- BPR(業務プロセス改革)
- 既存の組織や業務ルールを前提とせず、業務プロセス・組織構造・情報システムを根本から見直し、抜本的に再設計する取り組み。部分的な改善(カイゼン)とは異なる。
- BSC(バランススコアカード)
- 財務・顧客・業務プロセス・学習と成長という4つの視点から経営を評価し、戦略目標と日々の業務活動を結び付ける経営管理手法。財務指標だけに偏らない多面的な評価が特徴。
- Bulk Support(一括ロード)
- 大量の項目を並列に高スループットで投入する Cosmos DB SDK の機能(アトミックではない)。データ移行や大量ロード向け。アトミックな複数項目処理が要るなら Transactional Batch を使う。
- Business Critical レベル
- ローカル SSD と組み込みの Always On レプリカで低遅延・高可用性を提供する Azure SQL のサービスレベル。読み取りスケールアウト用のセカンダリも持つ。
- BYOD
- 従業員が私物のスマートフォンやノートPCを業務にも利用する運用形態(Bring Your Own Device)。コスト削減や利便性の一方、組織が管理しきれない端末が社内データにアクセスするリスクが生じるため、MDMによる管理やアプリ配布・暗号化の要件を課すことが多い。
- BYOK とインフラストラクチャ暗号化
- BYOK(Bring Your Own Key)で顧客管理キーをストレージ暗号化に持ち込み、さらにインフラストラクチャ暗号化を有効化して 256 ビット AES の二層でデータを保護する。
- B木インデックス
- 平衡木構造でキー値を整列して保持する、最も一般的なインデックス方式。範囲検索・等値検索・ソートいずれにも強く、多くの DBMS の既定のインデックス種別になっている。更新のたびに木の再平衡コストがかかる。
- CAAT(コンピュータ支援監査技法)
- コンピュータを利用して監査証拠の入手・分析を行う技法の総称。テストデータ法・並行シミュレーション法・ITF(統合テスト施設法)・監査モジュール法・汎用監査ソフトウェアによる全件検証などを含み、手作業では困難な大量データの検証やプログラムの処理内容そのものの検証を可能にする。
- CAB(変更諮問委員会)とECAB
- CAB(変更諮問委員会)は通常変更のリスク・影響・スケジュールを評価し、実施可否を助言する常設の会議体で、技術・業務・利用者など関係する立場を集めて意思決定を支える。ECAB(緊急変更諮問委員会)はCABを招集する余裕がない緊急変更のために、必要な少数の権限者だけで構成し迅速に承認する小規模編成である。ITサービスマネージャはCABの付議基準と構成を設計し、緊急時にはECABへ切り替えて評価の質と速度を両立させる。
- CALCULATE 関数
- フィルターコンテキストを変更して集計し直す DAX の中核関数。FILTER/ALL/USERELATIONSHIP などと組み合わせて条件付き集計を作る。
- Calendar のリソース
- 会議室や備品を Calendar に登録して予約できるようにする仕組み。予定の共有範囲(空き時間の見え方)も Calendar で管理する。
- Call Quality Dashboard(CQD)
- 多数の通話/会議の品質データを集約して傾向を分析し、品質問題が集中している拠点/サブネットを特定する。利用状況を集計する Teams usage reports とは別。
- CAN(Controller Area Network)
- 2本の差動信号線(CAN_H/CAN_L)で複数のノードが対等にバスを共有し、ノイズ耐性の高い車載・産業用のシリアル通信規格。メッセージにIDを付与し、複数ノードが同時送信した場合はID値が小さい(優先度が高い)メッセージが調停により優先されるため、衝突が発生してもデータ破損なく高優先度通信が確保される。
- CapEx(資本的支出)
- 設備や機器を前払いで購入・所有する支出。オンプレのデータセンター構築のように、大きな初期投資が発生し、資産として長期にわたり減価償却する。クラウド以前の伝統的なIT投資モデルの中心だった。
- CAPWAP
- 軽量AP(Lightweight AP)とWLCの間でトンネルを確立し、制御情報とクライアントデータを転送するためのトンネリングプロトコル。制御用のCAPWAPコントロールトンネルとデータ用のCAPWAPデータトンネルを分けて確立する。
- CAP定理
- 分散システムは一貫性(Consistency)・可用性(Availability)・分断耐性(Partition tolerance)の3つを同時に完全には満たせず、ネットワーク分断が起きた際にはCとAのどちらかを選ばざるを得ないという定理。NoSQL の設計思想(結果整合性の採用など)の理論的根拠になる。
- Carbon Footprint
- 自社の Google Cloud 利用に伴う炭素排出量を可視化し、サステナビリティの報告に使えるツール。
- Catalyst Center(旧DNA Center)
- Ciscoの企業ネットワーク向け一元管理コントローラ。機器の自動検出・一括プロビジョニング、SD-Accessのポリシー配布、アシュアランス(健全性の可視化)、REST APIによる自動化の起点を1つのダッシュボードに統合する。旧称DNA Center。
- CDN(コンテンツデリバリネットワーク)
- 利用者から地理的に近いエッジサーバにコンテンツをキャッシュして配信し、オリジンサーバまでの物理的距離・経路に起因する配信遅延を削減する仕組み。大規模な動画・Web配信で用いられ、オリジンの負荷軽減にも寄与する。
- CDP(Cisco Discovery Protocol)
- 隣接するCisco機器同士がデバイス種別・ホスト名・IPアドレス・接続ポートなどの情報をL2で交換し、トポロジを把握するためのCisco独自プロトコル。ベンダー非依存のLLDPと異なりCisco機器間でのみ動作するが、情報漏えいのリスクから外部接続ポートでは無効化することがある。
- CG(コンピュータグラフィックス)
- コンピュータを用いて画像や映像を生成・加工する技術全般。2Dのイラストやレンダリングから、3Dモデリング・アニメーションまで含み、映画・ゲーム・製品設計のシミュレーションなど幅広く応用される。
- chage(パスワードエージング)
- パスワードの有効期限を管理するコマンド。chage -l で現状表示、-M 90 で最長90日、-d 0 で次回ログイン時の変更を強制する。
- chain of custody(証拠保全の連鎖)
- インシデント対応で収集した証拠(ログ・ディスクイメージ等)について、誰がいつ何を収集・保管・受け渡ししたかを記録し続ける証拠保全の連鎖。記録が途切れると証拠の改ざんの可能性を否定できず、法的な証拠能力が損なわれる。
- CHECKPOINT
- ダーティページを即座にディスクへ書き出し、WAL の再生開始点を進めるSQLコマンド。定期的に自動実行されるチェックポイントを手動で即時実行したい場合(バックアップ前など)に使う。頻発させるとI/O負荷が急増する。
- child flows(子フロー)
- Power Automate で共通ロジックを切り出し複数フローから再利用するための子フロー。
- Chirp
- Google の音声向け生成モデル。元来は多言語の音声認識(文字起こし)用の基盤モデルで、後継の Chirp 3 では HD 音声合成(Text-to-Speech)にも対応する。
- chmod/umask
- chmod はパーミッションを変更する。数値モードは r=4・w=2・x=1 の合計を3桁で(chmod 754)、記号モードは u/g/o/a と +/-/= で指定する。umask は新規作成時に落とすビットの既定値で、ファイルは 666、ディレクトリは 777 からumask値を引いた権限になる(umask 022 → 644/755)。
- Chrome Browser Cloud Management
- 管理コンソールから Chrome のポリシー(起動ページ・同期・安全なブラウジング・機能の有効/無効)を一元配布する仕組み。OU 単位で出し分け、拡張機能は許可/ブロック+強制インストールで統制する。端末そのものを扱う ChromeOS デバイス管理とは別。
- CI/CD
- CI(継続的インテグレーション)はコード変更のたびに自動ビルド・自動テストを行い早期に不具合を検出する手法。CDには2つの意味があり、継続的デリバリーは本番リリースの直前まで(リリース可能な状態まで)を自動化し本番反映は手動承認を残す方式、継続的デプロイメントは本番反映まで全て自動化する方式を指す。
- CIA(機密性・完全性・可用性)
- 情報セキュリティの3要素:機密性(Confidentiality)・完全性(Integrity)・可用性(Availability)。
- CIDR 表記
- IP アドレス範囲を「/24」のようなプレフィックス長で表す記法。/24 は 256 個、/16 は 65,536 個のアドレスを含み、数字が小さいほど範囲が広い。VPC/VNet やサブネットの設計、ルーティングの最長一致判定、ファイアウォールルールの許可範囲指定など、あらゆるクラウドのネットワーク設計の基礎になる。
- CIEM
- クラウドインフラのエンタイトルメント管理(Cloud Infrastructure Entitlement Management)。Azure・AWS・GCP にまたがるアイデンティティの権限を継続的にスキャンし、実際には使われていない過剰な権限(オーバープロビジョニング)を可視化・縮小する。特権のジャストインタイム昇格を担う PIM とは役割が異なり、CIEM は「常に持っている権限そのものを削る」棚卸しの仕組み。
- Cisco Catalyst SD-WANとNSO
- Cisco Catalyst SD-WAN(旧Viptela)は拠点間のWAN接続を集中管理するコントローラベースのSD-WANソリューションで、Catalyst SD-WAN Manager(旧vManage)等のAPIから構成・監視を自動化する。NSO(Network Services Orchestrator)はマルチベンダ環境で、YANGサービスモデルとNETCONFを用いて複数機器への設定投入を宣言的に一括オーケストレーションするツール。
- Cisco Catalyst SD-WANのコンポーネント(vManage/vSmart/vBond/cEdge)
- Cisco Catalyst SD-WAN(旧Viptela)を構成する4つの主要コンポーネント。vManage(SD-WAN Manager)は構成・監視の管理プレーン、vSmartは経路とポリシーを配布する制御プレーン、vBondは各コンポーネント同士の初回認証と接続仲介を行うオーケストレーション、vEdge/cEdgeはトンネルを終端し実データを転送するデータプレーンを担う(cEdgeはIOS XEベース、vEdgeは旧Viptela OSベースのエッジルータ)。制御プレーンの経路配布にはOMP(Overlay Management Protocol)が使われる。なお現行ではvManageはCatalyst SD-WAN Managerに改称されている。
- Cisco SDK
- Ciscoの各プラットフォーム(Meraki・Catalyst Center・ACI等)のAPIを、生のHTTPリクエストを組み立てずにプログラミング言語から扱えるようにする開発者向けライブラリ群。認証やページネーション、エラー処理といった定型処理を吸収し、開発者はビジネスロジックに集中できる。
- Cisco TrustSec(SGT)
- IPアドレスではなくSGT(Security Group Tag)というグループ識別子でトラフィックを分類し、そのグループ同士の通信可否をSGACL等のポリシーとして一元的に定義・適用するグループベースのセグメンテーション技術。端末のIPアドレスやVLANが変わってもグループの所属に基づき一貫したポリシーを適用できる。
- CISCとRISC
- CPUの命令セット設計の思想。CISCは1命令で多くの処理を行う複雑・多機能な命令を持ち、1命令の実行に複数クロックを要することが多い方式。RISCは命令を単純なものに絞り、1命令をほぼ1クロックで実行してパイプライン処理で高速化する方式。
- CISO(最高情報セキュリティ責任者)とセキュリティ委員会
- CISOは組織の情報セキュリティ全般について経営レベルで責任を負う役員級の役職で、経営戦略とセキュリティ投資・対策を結び付ける役割を担う。セキュリティ委員会はCISOのもとで各部門の代表者が参加し、全社的な方針の審議や部門横断の課題調整を行う組織体で、特定部門だけの判断による偏りやサイロ化を防ぐ。両者は情報セキュリティを一部門任せにせず、組織全体で推進するための体制の核となる。
- Classic VPN
- 単一トンネルのゲートウェイで SLA 保証のない旧世代の IPSec VPN。ルートベース(動的)とポリシーベース(静的トラフィックセレクタ指定)の 2 方式があり、後者は特定の相手先ネットワーク機器との互換性のためだけに残っている。Google は非推奨とし、新規構築では HA VPN を案内する。
- Client API object model
- model-driven フォームを JavaScript で操作する API。formContext(フォーム/属性/コントロール)と executionContext(イベント情報)を使い、OnLoad/OnChange/OnSave に登録する。
- clone
- 既存リポジトリを履歴ごとローカルに複製する操作(git clone)。
- Cloud App Discovery
- ファイアウォール/プロキシのログを解析して未承認のクラウド アプリ(シャドー IT)を発見しリスク スコアを付ける機能。接続済みアプリを深く制御する app connector とは別。
- Cloud Audit Logs
- 誰がいつ何をしたか(管理操作・データアクセス)を記録する監査ログ。デプロイの追跡や統制・規制対応に使う。データアクセス監査は明示的に有効化する。
- Cloud Billing(課金)
- 請求先アカウントをプロジェクトに紐づけ、費用の確認・予算アラート・課金データの BigQuery エクスポートを行う仕組み。
- Cloud Build
- ソースコードの取得・ビルド・テスト・コンテナイメージ化を自動実行するサーバーレス CI サービス。cloudbuild.yaml でビルドステップを定義し、GitHub/Cloud Source Repositories への push をトリガーに実行できる。生成物は Artifact Registry へ保存するのが一般的。
- Cloud CDN
- 外部 Application LB のバックエンドで有効化し、Google のエッジでコンテンツをキャッシュする CDN。オリジンは MIG/Cloud Storage/Cloud Run/インターネット NEG。更新時はキャッシュ無効化で古い内容を破棄する。
- Cloud CLI エミュレータ
- Google Cloud CLI が提供する Firestore・Pub/Sub・Spanner などのローカル模擬環境。クラウドに接続せず開発・ユニットテストを高速化する(本番の代替ではない)。
- Cloud Code
- VS Code や IntelliJ 等の IDE に組み込む拡張機能。Kubernetes マニフェストや Dockerfile の作成支援、ローカルからの GKE/Cloud Run へのデプロイ、リモートクラスター上でのライブデバッグをエディタ内から行える。
- Cloud Composer
- Apache Airflow ベースのマネージドなオーケストレーション。依存のある複数ステップのパイプラインをスケジュール・実行する。
- Cloud Data Fusion
- コードをあまり書かずにビジュアルで ETL/ELT パイプラインを構築できるマネージドサービス。
- Cloud Deploy
- GKE・Cloud Run・Anthos 向けのマネージドな継続的デリバリー(CD)サービス。開発→ステージング→本番のようなデリバリーパイプラインをテンプレート化し、カナリアやブルー・グリーンなどのデプロイ戦略、承認ゲート、ロールバックを標準機能として提供する。
- Cloud Digital Leader
- Google Cloud の製品とサービスをビジネス課題の解決にどう活かすかを問う、Google Cloud の入門(Foundational)認定資格。
- Cloud DNS
- 内部/外部の名前解決(ドメイン名から IP へ)を管理する Google Cloud のサービス。
- Cloud DNS ルーティングポリシーと分割ホライズン
- Cloud DNS の高度な解決機能。ジオロケーション(送信元地域で応答変更)とフェイルオーバー(プライマリ障害でバックアップへ)のルーティングポリシー、公開/非公開ゾーンで同名を別解決する分割ホライズン DNS を含む。
- Cloud Endpoints
- OpenAPI/gRPC の API を Extensible Service Proxy 経由で管理し、認証・モニタリング・割り当てを付与する API 管理サービス。
- Cloud External Key Manager(Cloud EKM)
- 外部(自社/サードパーティ)の鍵管理基盤に保持した鍵で Google Cloud のデータを暗号化する仕組み。CMEK(Cloud KMS で顧客管理)よりさらに鍵主権を高める。
- Cloud Functions
- 「ファイルがアップされたら実行」のようなイベント駆動の小さな処理を動かすサーバーレスの関数サービス。
- Cloud HSM
- FIPS 140-2 Level 3 準拠の耐タンパなハードウェア(HSM)で暗号鍵を保護するサービス。ソフトウェア鍵より高い保証が要るときに選ぶ。CMEK のバックエンドとして使える。
- Cloud IAM
- 「誰(メンバー)に・どのロール(権限)を・どのリソースで」許可するかを定めるアクセス管理。最小権限が原則。
- Cloud Identity
- ユーザーとグループを管理し、外部 ID プロバイダーと SAML SSO や Directory Sync / GCDS で連携する Google のサービス。
- Cloud IDS
- ネットワーク層の侵入や既知の脅威シグネチャを検出するマネージドな侵入検知サービス(IDS)。Packet Mirroring を用いてトラフィックを検査する。横断的な Security Command Center とは守備範囲が別。
- Cloud Interconnect
- オンプレミスと Google Cloud を専用回線で接続するサービス(Dedicated/Partner)。高帯域・低遅延・SLA を提供し、手軽な暗号化トンネルの Cloud VPN と使い分ける。
- Cloud KMS
- 暗号鍵を作成・管理し、ローテーションや無効化を制御するマネージドな鍵管理サービス。CMEK の基盤。
- Cloud Load Balancing
- 用途で選ぶロードバランサー:グローバル外部アプリケーション LB(L7・世界中の利用者を最寄りへ)、内部 LB(内部マイクロサービス)、ネットワーク LB(L4・TCP/UDP)。
- Cloud Logging
- ログの収集・検索・保管を担う Google Cloud Observability の機能。原因調査や監査に使う。
- Cloud Monitoring
- メトリクスの監視・ダッシュボード・アラートを担う Google Cloud Observability の機能。
- Cloud NAT
- 外部 IP を持たない VM から、インターネットへの外向き通信を可能にするサービス。
- Cloud NGFW と階層型ファイアウォール
- VPC 内通信を制御する次世代ファイアウォール。組織/フォルダに継承する階層型ポリシー、優先度で評価される実効ポリシー、Enterprise ティアの L7 検査(IPS)を持つ。タグ/サービスアカウントでマイクロセグメンテーションを実装する。
- Cloud PKI(Intune Suite)
- Intune Suite のアドオンで、オンプレミスの PKI(証明書発行局)を構築せずに、クラウド上でルート/発行 CA を作成し証明書のライフサイクル(発行・更新・失効)を自動化するサービス。Wi-Fi や VPN、認証用の証明書配布プロファイルと組み合わせて使う。
- Cloud Router
- オンプレ/他ネットワークと BGP で動的に経路交換するルーター。ASN・ルート優先度/MED・認証を構成し、カスタムアドバタイズ/ラーン ルートで広告・学習する範囲を制御する。
- Cloud Run
- コンテナをサーバーレスで実行するサービス。トラフィックがなければゼロまで縮小し、使った分だけ課金される。
- Cloud Run のリビジョンとトラフィック分割
- デプロイごとに作られる不変の単位がリビジョン。トラフィック分割で各リビジョンへ送る割合を制御し、カナリア公開やロールバックを行う。
- Cloud Scheduler
- 汎用的に時刻ベース(cron)でジョブを起動するマネージドのスケジューラ。
- Cloud Shell(Google Cloud)
- ブラウザから使える一時的なコマンドライン環境。gcloud などのツールが事前導入され、認証済みで即操作できる。
- Cloud SQL
- MySQL / PostgreSQL / SQL Server 互換のマネージド リレーショナルデータベース。一般的な業務アプリ向け。
- Cloud SQL Auth Proxy
- 公開 IP を露出させずに、IAM 認証と暗号化で Cloud SQL へ安全に接続するためのプロキシ。アプリからの DB 接続の推奨手段。
- Cloud Storage
- 画像・動画・バックアップなど非構造化データを保存するオブジェクトストレージ。
- Cloud Storage のストレージクラス
- アクセス頻度で選ぶクラス:Standard(頻繁)/Nearline(月1)/Coldline(四半期)/Archive(長期低頻度)。低頻度ほど保存は安いが取り出しは高い。
- Cloud Trace
- 分散システムのリクエストの経路(スパン)を追跡し、レイテンシのボトルネックを特定する分散トレースのサービス。メトリクス(Monitoring)やログ(Logging)とは別の観測軸。
- Cloud VPN
- オンプレミスや他ネットワークと Google Cloud を暗号化トンネルで接続するサービス。
- Cloud Workstations
- ブラウザまたはローカル IDE からアクセスするマネージドなクラウド開発環境。カスタムコンテナイメージでチーム標準の開発環境を定義し、VPC 内に閉じて配置できるためソースコードを個人端末に置かずにセキュアな開発ができる。利用時間に応じた課金で、アイドル時は自動停止する。
- CloudFormation テンプレートの構成
- テンプレートの主要セクション。Parameters=入力値、Mappings=環境/リージョン別の対応表、Conditions=条件分岐、Resources=作成物(必須)、Outputs=出力(他スタックへ Export)。これらで再利用可能で環境差を吸収する IaC を書く。
- CloudFormation の検証(Hooks/Guard/Linter)
- テンプレート品質と統制の道具。cfn-lint=構文/ベストプラクティス検査。CloudFormation Guard(cfn-guard)=ポリシー・アズ・コードで規約準拠を検証。Hooks=プロビジョニング前にカスタム検査を強制。ドリフト検出と組み合わせて構成統制を保つ。
- CloudFormation 組み込み関数(Ref/GetAtt/Sub)
- テンプレートで値を動的に解決する関数。Ref=パラメータ/リソースの参照、Fn::GetAtt=リソースの属性取得(ARN・エンドポイント等)、Fn::Sub=文字列に変数を埋め込み、Fn::Join/Fn::If など。ハードコードを避け、移植性を高める。
- CloudFront オリジングループ(オリジンフェイルオーバー)
- プライマリとセカンダリのオリジンを束ね、特定のエラー応答時に自動でセカンダリへ切り替える高可用構成。S3 と別リージョンの S3 や ALB を組み合わせて配信元の冗長化を行う。
- CloudFront キャッシュポリシー
- CloudFront がオブジェクトをキャッシュする際の TTL(最小/既定/最大)と、キャッシュキーに含める要素(ヘッダー・クエリ文字列・Cookie)を定義する設定。キャッシュキーを絞るほどヒット率が上がりオリジン負荷が下がるため、レスポンスをどこまで動的に出し分けるかとのトレードオフになる。
- CloudFront のオリジン保護(OAC)とエッジ関数
- Origin Access Control(OAC、旧 OAI)は S3 を非公開のまま CloudFront 経由のアクセスだけを許可する仕組みで、SSE-KMS や全リージョン・全 HTTP メソッドに対応する現行の推奨。エッジでのコード実行は、超軽量・ビューワーのみの CloudFront Functions(ヘッダー操作/リダイレクト/URL 書き換え)と、オリジンイベントや外部呼び出しも可能な Lambda@Edge を用途で使い分ける。
- CloudFront 自動圧縮(コンテンツ圧縮)
- CloudFrontがオリジンからのレスポンスをGzipやBrotliで自動圧縮し、転送量を削減して表示を高速化する機能。オリジンが未圧縮で返し、対象のContent-Type(HTML/CSS/JS等のテキスト系)かつファイルサイズが1,000〜10,000,000バイトの範囲にある場合にのみ適用され、キャッシュビヘイビアで有効化する。ビューワーのAccept-Encodingヘッダーを見て対応形式(gzip/br)を選択する。
- CloudFront 署名付き URL
- 個別ファイル単位で有効期限・IP・カスタムポリシーを指定してアクセスを制限する URL。1つの署名付き URL は1つのオブジェクトにのみ対応するため、多数のファイル(動画のセグメント等)を配信する場合はリクエストごとに生成する手間がかかる。CloudFront キーペア(または信頼された鍵グループ)で署名する。
- CloudFront 地理的制限(Geo Restriction)
- ディストリビューション単位で、国コードによる許可リスト(ホワイトリスト)または拒否リスト(ブラックリスト)を設定し配信を制御する機能。コンテンツライセンスや輸出規制など地域限定要件への対応に使う。IP位置情報ベースで判定するため、VPN経由のアクセスでは回避されうる。
- CloudFront 無効化(Invalidation)
- パスを指定して CloudFront エッジに残るキャッシュを TTL 期限前に強制的に削除し、次のリクエストでオリジンから最新のコンテンツを取得させる操作。月 1,000 パスまでは無料枠があるが、頻繁な無効化はコストと若干の遅延を伴うため、本来はキャッシュポリシーやバージョニングされたファイル名での回避が推奨される。
- CloudTrail イベント種別(管理/データ/Insights)
- 管理イベント=API による設定操作(既定で記録・無料)。データイベント=S3 オブジェクトや Lambda 実行などの高頻度データ操作(任意・有料)。Insights イベント=普段と異なる API 呼び出し量を異常検知する。
- CloudTrail の高度な構成
- 組織証跡(Organization Trail)で全アカウントを一元記録し、ログファイル検証で改ざんを検知、データイベントで S3 オブジェクトや Lambda 呼び出しを詳細記録する。CloudTrail Lake で SQL クエリ分析する。
- CloudWatch Contributor Insights
- ログから「上位の貢献者」(最もエラーを出す IP・最も遅い API・最頻アクセス項目など)をルールでランキング表示する機能。負荷の偏りや異常な発信元の特定に使う。
- CloudWatch Internet Monitor
- AWSリソースとインターネット上のエンドユーザーとの間の経路の可用性・パフォーマンスを、都市や通信事業者ごとに可視化するサービス。AWSが観測する膨大な通信データを使い、リージョン外の一般利用者視点の問題(ISP障害等)を検知できる。
- CloudWatch Logs
- ログを集約・保存する仕組み。ロググループ(保持期間を設定)の配下にログストリームが並ぶ。メトリクスフィルターでログから数値メトリクスを抽出し、サブスクリプションフィルターで Kinesis/Lambda/OpenSearch へリアルタイム転送する。Lambda など多くのサービスのログが自動で届く。
- CloudWatch Logs Insights
- CloudWatch Logs に貯めたログを専用クエリ言語で対話的に分析する機能。fields/filter/stats/sort/limit などでフィルタ・集計し、エラー件数や上位 IP などを素早く可視化する。スキャンしたデータ量に応じて課金。
- CloudWatch Network Monitor
- オンプレミスとAWSを結ぶハイブリッド接続(Site-to-Site VPN・Direct Connect)のネットワーク経路を能動的にプローブし、レイテンシやパケットロスを監視するサービス。障害箇所がAWS側かオンプレ側かの切り分けに使う。
- CloudWatch ServiceLens
- メトリクス・ログ・X-Ray トレースを 1 画面で相関付けて表示する CloudWatch の機能。サービスマップ上でレイテンシやエラーの発生箇所を視覚的に特定でき、分散システムの根本原因分析(RCA)を素早く進められる。
- CloudWatch Synthetics
- カナリア(設定可能なスクリプト)を定期実行し、エンドポイントやユーザーフローをユーザー視点で外形監視する CloudWatch の機能。実際のリクエストが届く前に可用性低下やレイテンシ悪化を検知でき、SLA 監視やヘルスチェックの補完に使う。
- CloudWatch アラーム(複合・異常検出)
- メトリクスがしきい値を超えたら通知/アクションを起こすアラーム。複合アラームで複数条件を AND/OR 結合し、異常検出で動的なベースラインから外れを検知する。
- CloudWatch アラームの状態
- アラームは 3 状態をとる。OK=しきい値内。ALARM=しきい値を超過。INSUFFICIENT_DATA=データ不足(起動直後やメトリクス欠落)。状態遷移ごとにアクション(SNS 通知・Auto Scaling・EC2 アクション)を発火できる。
- CloudWatch エージェント
- EC2 のメモリ使用率やディスク空き容量などゲスト OS 内のメトリクスは標準では取得できず、導入が必要なエージェント(SOA 頻出のひっかけ)。ログの収集も担う。
- CloudWatch クロスアカウント可観測性(OAM)
- Observability Access Manager で、複数のソースアカウントのメトリクス・ログ・トレースを 1 つのモニタリングアカウントに集約して一元監視する仕組み。マルチアカウント環境の運用を簡素化する。
- CloudWatch ダッシュボードと Synthetics
- メトリクス/ログを 1 画面に可視化するダッシュボードと、外形監視のカナリア(Synthetics)でエンドポイントの可用性・応答を継続テストする。
- CloudWatch ダッシュボード共有
- CloudWatch ダッシュボードを、AWS アカウントを持たない社外の関係者や未ログインユーザーへ安全に共有できる機能。共有方法は、特定のメールアドレス(最大5件、Cognitoベースの各自パスワード)へ招待する方式、単一ダッシュボードを認証なしの公開リンクとして共有する方式、アカウント内の全ダッシュボードをSSO/SAML連携で共有する方式の3種類がある。IAM権限を付与せずに閲覧専用アクセスを提供したい場合(ステータスページ的な用途)に使う。
- CloudWatch メトリクス
- CloudWatch が扱う数値の時系列データ。名前空間とディメンションで識別し、アラームやダッシュボードの入力になる。EC2 等の標準メトリクスが自動で集まる。
- CloudWatch メトリクスストリーム
- メトリクスを Data Firehose 経由でほぼリアルタイムに S3 やサードパーティ(Datadog 等)へ継続配信する機能。ポーリング型の GetMetricData より低遅延・低負荷で外部監視基盤と連携できる。
- CLUSTER
- 指定したインデックスの物理順に合わせてテーブルの行を並べ替えて再格納する SQL コマンド。範囲検索の局所性(correlation)を高め I/O を減らせるが、実行中はテーブルへの排他ロックがかかり、以後の追加行は自動的にはクラスタ順を維持しない。
- CMDB(構成管理データベース)
- CMDB(構成管理データベース)は、構成品目(CI)とその属性、およびCI間の相互関係を記録するデータベースで、構成管理の中核となる情報基盤である。変更やリリースの影響分析、インシデントの原因追跡、サービス構成の可視化に用いられ、情報の正確さと最新性が価値を左右する。ITサービスマネージャはCMDBの記録範囲と更新プロセスを設計し、変更管理と連動して実態との乖離(ドリフト)を防ぐことで、影響評価の信頼性を担保する。
- CNN(畳み込みニューラルネットワーク)
- 畳み込み層とプーリング層を組み合わせて画像などの空間的な特徴を段階的に抽出する深層学習のモデル。画像認識や物体検出で高い性能を発揮する代表的なアーキテクチャ。
- COBIT
- ISACAが策定したITガバナンス・ITマネジメントのフレームワーク。統制目標を体系的に整理し、システム監査人が統制の整備・運用状況を評価する際のよりどころ(監査規準・評価基準)として用いる。監査人は監査対象の統制がCOBITの目標に照らして十分かを判断材料にする。
- Code scanning
- CodeQL などでコードを静的解析し、脆弱性やバグを検出する機能(GHAS)。
- Code Security
- ソースコードを静的解析(SAST)して脆弱性を検出する GitHub の機能「Code Scanning」の中核。既定エンジンは CodeQL で、コードをデータベース化しデータフロー解析(source→sink)で危険な経路を見つける(サードパーティ SAST ツールも統合可能)。なお「GitHub Code Security」は 2025 年に登場したサブスクリプション製品プラン名(Code Scanning・Copilot Autofix 等を含む)であり、Code Scanning 機能そのものの改称ではない点に注意。
- CodeDeploy のデプロイ構成
- CodeDeploy の概念整理。デプロイタイプ=インプレース or ブルー/グリーン(EC2/オンプレ)。デプロイ構成(deployment configuration)=トラフィック移行や正常ホスト数の規則で、Lambda/ECS は Canary/Linear/AllAtOnce、EC2 は最小正常ホスト数(OneAtATime/HalfAtATime 等)。フックとアラームで自動ロールバックする。
- CodeDeploy(デプロイグループ/エージェント)
- デプロイグループ=対象(EC2 タグ・ASG・ECS/Lambda)と方式(インプレース/Blue-Green・カナリア/線形)をまとめた単位。appspec.yml でライフサイクルフックを定義し、検証して失敗時は自動ロールバックする。EC2 には CodeDeploy エージェントが必要。
- CODEOWNERS
- 特定パスを変更する PR に、自動でレビュアーを割り当てるための定義ファイル。
- CodePipeline(ステージ/アクション/承認)
- CI/CD のオーケストレーター。パイプラインはステージ(ソース→ビルド→テスト→デプロイ)で構成し、各ステージはアクションを持つ。手動承認アクションで本番前にゲートを置ける。アーティファクトを S3 経由で受け渡す。
- CodeQL クエリスイート
- 「どのルールを実行するか」を決める集合。既定(default)は誤検知少なめ、security-extended は広く検出(ノイズも増えうる)、組織独自のカスタムクエリも追加できる。検出範囲と誤検知のバランスを取る。
- Colab Enterprise
- 使い慣れた Colab のノートブック体験を Google Cloud の IAM・VPC・データガバナンスと統合したエンタープライズ版。個人向け Colab と異なりリソースは顧客の Google Cloud プロジェクト内で実行され、チームでの共同編集や権限管理がしやすい。手軽さ重視の共同作業に向く。
- Collect・ClearCollect 関数(コレクション)
- アプリ内の一時的な表データ(コレクション)にレコードを追加/初期化する関数。一時データの保持やオフライン処理に使う。
- Compute Engine
- Google Cloud の IaaS。CPU/メモリを選べる仮想マシン(VM)を提供し、OS まで自分で管理できる。既存システムのリフト&シフト先に適する。
- Concatenate(文字列結合)
- 複数の文字列を 1 つにつなげる関数(&演算子でも可)。氏名の連結や表示用テキストの組み立てに使う。
- concurrency(同時実行制御)
- 同じグループの実行を同時に 1 つに制限する仕組み。cancel-in-progress: true で新しい実行開始時に進行中の古い実行を自動キャンセルし、最新だけ検証してコストを節約できる。
- Confidential Computing
- 処理中(使用中・メモリ上)のデータを暗号化された VM/ノードで扱い、ホストや他テナントから保護する仕組み。保存時/転送時の暗号化とは別の保護面(data in use)。
- Config Connector
- Kubernetes の宣言的な方法で Google Cloud リソースを管理する Infrastructure as Code ツール。
- Config アグリゲーターと組織コンプライアンス
- 複数アカウント/複数リージョンの AWS Config データを 1 か所に集約し、組織全体のリソース構成と準拠状況を一元的に評価・可視化する。
- Config 設定レコーダー
- AWS Config の中核機能で、対象リソースの構成変更を継続的に検知し、設定項目(Configuration Item)として時系列に記録する。レコーダーを有効化しないと Config ルール評価もタイムラインの参照もできず、リージョンごとに個別に有効化が必要。
- connected organizations(接続された組織)
- エンタイトルメント管理で、信頼する外部パートナー組織を登録し、その組織の人にアクセスパッケージを申請させる仕組み。承認時に外部ゲストを作成し、外部ユーザーのライフサイクルで失効させる。
- Contact Center as a Service(CCaaS)
- クラウドで提供されるコンタクトセンター基盤の総称(SaaS 型でマルチチャネル対応、オンプレ設備不要。例:Amazon Connect、Genesys Cloud、Five9 等)。Google Cloud 文脈では Customer Engagement Suite に含まれる Google の CCaaS 製品が該当し、Conversational Agents や Agent Assist と組み合わせて顧客対応を自動化・支援する。
- Container Insights / Lambda Insights
- ECS/EKS のコンテナと Lambda 関数向けに、CPU・メモリ・ディスク・ネットワークなどの詳細な運用メトリクスとログを自動収集する CloudWatch の拡張機能。ダッシュボードや異常検出アラームの入力として、コンテナ/サーバーレス基盤特有のボトルネックを可視化する。
- Content explorer(コンテンツ エクスプローラー)
- Microsoft Purview のツールで、機密ラベルや機密情報の種類(SIT)が適用されたアイテムの実際の中身と保存場所(SharePoint・Exchange・OneDrive 等)を可視化する。何がどこにあるかのスナップショットであり、誰が何をしたかの操作履歴を追う Activity explorer とは目的が異なる。閲覧には追加の権限(コンテンツの表示)が必要。
- Conversational Agents
- 自然言語で対話する対話型エージェント/チャットボットを構築し、顧客サポートなどを自動化するソリューション。
- Copilot Analytics
- Copilot の利用状況・採用状況を可視化するレポート機能。Microsoft 365 管理センターと併せて活用促進やライセンス最適化に使う。
- Copilot Chat
- 自然言語で質問・コード生成・説明・修正・テスト作成を依頼できる会話型のサーフェス。選択範囲やファイルを文脈として渡せる。
- Copilot Code Review ポリシー
- 組織の基準に沿って Copilot のコードレビュー支援を展開するためのポリシー。人によるレビューを置き換えるものではない。
- Copilot コントロール
- アプリ内にチャット型の AI アシスタントを埋め込み、ユーザーがアプリのデータに自然言語で質問・操作できるキャンバスアプリのコントロール。
- Copilot のライセンスと課金
- Copilot には固定の月額ライセンスと、使った分だけの従量課金(pay-as-you-go, PAYG・SharePoint のエージェント等に適用)がある。PAYG は課金ポリシーでコストを管理する。ライセンスは Microsoft 365 管理センターでユーザー/グループに割り当てる。
- Copilot の従量課金(PAYG)
- 月額固定ライセンスとは別に、使った分だけ課金する Copilot のモデル。SharePoint のエージェント等に適用され、課金ポリシーでコストを管理する。
- Copilot 管理(利用監視・プロンプト)
- Copilot Analytics や Microsoft 365 管理センターのレポートで利用状況・採用状況を監視し、活用促進やライセンス最適化につなげる。プロンプトの管理では、よく使うプロンプトを保存・共有・スケジュール・削除して組織で再利用・標準化する。
- Copilot 組織ポリシー(機能の可用性)
- Enterprise/組織レベルで、どの Copilot 機能を誰がどう使えるかを管理する設定。IDE と github.com の双方に及び、個人設定より上位。
- Copilot 対応エディタ/IDE
- GitHub Copilot は Visual Studio Code・Visual Studio・JetBrains 系 IDE・Neovim などに拡張として組み込んで使える。補完や Chat はエディタ上で動作する。
- CoPP(Control Plane Policing)
- ルータ/スイッチのコントロールプレーン(CPU)宛てのトラフィックにポリシング(レート制限)を適用し、過大なトラフィックによるCPU枯渇を防ぐセキュリティ機能。宛先が装置自身であるパケット(ルーティングプロトコル・管理アクセス・ICMP等)を分類し、種類ごとに許容レートを設定してCPUをDoS攻撃や誤設定による過負荷から保護する。
- Copy アクティビティ
- 大量データを高速に搬送するパイプラインのアクティビティ。増分はウォーターマーク列で前回以降だけを取り込む。
- COPY 文と \copy
- テーブルとファイルの間で一括データ入出力を行う手段。SQL の COPY 文はサーバプロセスの権限でサーバ側のファイルを直接読み書きする。psql のメタコマンド \copy はクライアント側の権限でファイルを扱い、内部的に COPY を発行する。
- correlation(統計)
- カラムの値の並び順と物理的な格納順との相関を -1〜1 で表す統計値。1に近いほど物理順とソート順が一致し、Index Scan がディスク上でも順序よく読めるため有利になる(プランナがスキャン方式を選ぶ材料の一つ)。
- Cosmos DB の API
- Cosmos DB はワークロードに合わせて複数の API を選べる。NoSQL(ドキュメント・既定)・MongoDB・Cassandra・Gremlin(グラフ)・Table。既存アプリの移行や用途で選ぶ。
- Cosmos DB の SDK 操作
- CosmosClient でデータベース/コンテナー/アイテムを作成・読み取り・クエリ・更新する開発操作。要求コストは RU で計測される。
- COSO(内部統制フレームワーク)
- トレッドウェイ委員会組織委員会(COSO)が公表した内部統制の枠組み(COSOキューブ)。統制環境・リスク評価・統制活動・情報と伝達・モニタリングの5構成要素からなり、業務の有効性・効率性、財務報告の信頼性、法令遵守の3目的を達成するための基盤となる。監査人は内部統制の整備状況をこの5要素に沿って評価する。
- Cost Optimization Hub
- 組織全体のコスト削減の機会(未使用リソース・適正化・Savings Plans/RI 推奨)を 1 か所に集約し、削減見込み額順に提示する Billing の機能。Compute Optimizer や Trusted Advisor の推奨を横断的にまとめる。
- CPU クレジット(バーストパフォーマンス)
- T 系インスタンスはベースライン性能を超えるとき CPU クレジットを消費してバーストする。アイドル時に貯まり、不足すると性能が制限される。Unlimited モードでは追加課金で継続バーストできる。安定して高負荷なら C/M 系が適切。
- CPUとクロック周波数
- CPU(中央処理装置)は演算・制御を担うコンピュータの中枢。クロック周波数はCPUが1秒間に処理できる信号の回数(Hz単位)を表し、一般に数値が大きいほど処理速度が速い目安になる。
- CQRS
- コマンド(書き込み)とクエリ(読み取り)のモデル・経路を分離するアーキテクチャパターン(Command Query Responsibility Segregation)。読み取りと書き込みで負荷特性が大きく異なる場合に、それぞれを独立に最適化・スケールできる。
- CREATE INDEX CONCURRENTLY
- 書き込みをブロックせずにインデックスを作成できるオプション。通常の CREATE INDEX に比べ低速で、トランザクション内では実行できず、途中でエラーが起きると INVALID な不完全インデックスが残置されるため、状態確認と必要に応じた DROP INDEX・再実行が必要になる。
- CREATE STATISTICS / pg_statistic_ext
- 複数列間の相関(論理的に強く結びついた列同士)を捉える拡張統計。CREATE STATISTICS で統計オブジェクトを定義(カタログ pg_statistic_ext に登録)し、ANALYZE 後に実際の統計データが pg_statistic_ext_data へ格納される。単一カラム統計だけでは過小/過大評価しやすい複合WHERE句の選択率推定を改善する。種類は3つあり、ndistinct は列の組み合わせの個別値数、dependencies(functional dependencies)は列間の関数従属性、mcv(most-common-values)は列の組み合わせの頻出値リストをそれぞれ捉える。
- createdb/dropdb
- データベースを作成・削除するコマンドラインラッパー。内部的には CREATE DATABASE/DROP DATABASE 文を発行する。createdb は -T オプションでコピー元テンプレートを指定できる。
- createuser/dropuser
- ロール(ユーザー)を作成・削除するコマンドラインラッパー。内部的にはそれぞれ CREATE ROLE/DROP ROLE 文を発行する。
- CRM(顧客関係管理)
- 顧客との関係を構築・維持し、顧客満足度やリピート率の向上を図る経営手法・システム。顧客の購買履歴や問い合わせ履歴を一元管理して活用する。
- cron/crontab(定期実行)
- 決まった時刻に処理を定期実行する仕組み。crontab -e で編集し、書式は「分 時 日 月 曜日 コマンド」。ユーザー分は /var/spool/cron/、システム分は /etc/crontab(ユーザー欄あり)や /etc/cron.d/、cron.{hourly,daily,weekly,monthly}/。利用制限は cron.allow/cron.deny(allow があれば allow 優先)。
- Cross-Cloud Interconnect
- 他のパブリッククラウドと Google Cloud を、インターネットを経由せず専用の物理接続で低遅延に結ぶサービス。マルチクラウド接続で Cloud VPN より高帯域・低遅延が必要なときに使う。
- Cross-Region Inference(クロスリージョン推論)
- Amazon Bedrock の推論プロファイルで、推論リクエストを複数リージョンへ自動的に振り分ける機能。単一リージョンの容量不足やリージョン障害を吸収して可用性を高める(データ複製ではなく推論のルーティング)。
- Cross-tenant access 設定
- 相手テナントごとに「受信/送信のアクセス」と「相手の MFA/デバイス準拠の主張を信頼するか」を細かく制御する設定。テナント間同期(ユーザーの自動プロビジョニング)とは役割が異なる。
- CRUD操作
- データやリソースに対する基本操作の頭文字。作成(Create)・読み取り(Read)・更新(Update)・削除(Delete)を指し、RESTful APIではそれぞれ一般にHTTPのPOST・GET・PUT(またはPATCH)・DELETEに対応する。
- CRUD分析(CRUDマトリクス)
- 機能(プロセス)とデータ(エンティティ)を縦横に配した表に、各機能が各データに対して行う生成(Create)・参照(Read)・更新(Update)・削除(Delete)を記入して整合性を検証する手法。どのデータも生成する機能や参照する機能が存在するか、更新権限に漏れや重複がないかを点検し、機能とデータの過不足を洗い出す。システムアーキテクトが機能分割やアクセス権設計の妥当性を確認する際に用いる。
- CRYPTREC暗号リスト
- 日本の電子政府で利用する暗号技術の安全性を評価・監視する CRYPTREC が公表する暗号リスト。「電子政府推奨暗号リスト」「推奨候補暗号リスト」「運用監視暗号リスト(互換性維持のため継続利用は認めるが新規利用は非推奨)」の3つで構成される。危殆化(鍵長不足やアルゴリズムの弱点発見)が判明した暗号はリストの見直しで推奨から外される。
- CSF(重要成功要因)
- 経営目標であるKGIを達成するために、特に重視して取り組むべき要因(成功の鍵)。KGI(ゴール)→CSF(鍵)→KPI(中間指標)という関係で位置づけられ、限られた経営資源をどこへ集中させるべきかを明確にする役割をもつ。
- CSIRT(シーサート)
- コンピュータセキュリティにかかわるインシデントに対応するための組織内チーム。インシデントの検知・分析・対応・再発防止までを担い、社外のCSIRTや関係機関と情報連携することもある。
- CSIRT運用とSOC
- CSIRTがインシデント対応の司令塔である一方、SOC(セキュリティオペレーションセンター)はログやアラートを24時間365日監視し、脅威の検知・一次分析を担う実働部隊。中小組織では自前で持たずMSSP(マネージドセキュリティサービス)に監視業務を委託することも多い。
- custom API(カスタム API)
- Dataverse 内に定義する再利用可能な独自操作(メッセージ)。特定テーブルに紐づく bound と、テーブル非依存の unbound がある。プラグインで実装。外部 API を取り込むカスタムコネクタとは別物。
- Custom Vision
- 自分の画像で学習させ、独自の画像分類器・物体検出を作るサービス。
- Custom Vision の学習(分類/検出・mAP)
- 画像分類と物体検出から課題に合うモデルを選び、画像にラベル付け→転移学習で訓練→精度・再現率・mAP で評価→公開して利用する。
- cut
- 各行から指定したフィールドや文字位置を切り出す。-d で区切り文字、-f でフィールド番号を指定する(cut -d, -f2 で CSV の2列目)。
- CV(コスト差異)
- CV = EV − AC で算出するコストの超過・節約を示す指標。正の値は予算内(コスト超過なし)、負の値は予算超過を意味し、SVと組み合わせて診断すること(例:SPI低・CPI低なら遅延かつ超過)で是正措置を判断する。
- CVE
- Common Vulnerabilities and Exposures。特定の製品/版の個別の脆弱性に付く一意の ID(例: CVE-2024-XXXXX)。脆弱性の「事例」を指す。
- CVSS(深刻度)
- Common Vulnerability Scoring System。脆弱性の深刻度を数値化する標準。優先順位付けでは EPSS(悪用確率)や到達可能性・資産重要度と併用する。
- CWE
- Common Weakness Enumeration。SQL インジェクションやバッファオーバーフローなど弱点の「種類」の分類(例: CWE-89)。CVE が「事例」、CWE が「種類」。
- DALL-E(画像生成)
- Azure OpenAI のテキストから画像を生成するモデル。プロンプトに基づき画像を作成・編集する。
- Data Activator(Activator)
- データが条件(しきい値など)を満たしたら通知やアクションを自動で起動する Fabric の機能。Real-Time Intelligence の一部。
- Data Firehose の機能(バッファリング/変換/動的パーティショニング)
- バッファリング=サイズ/時間で溜めてから配信(小さなファイルの乱立を防ぐ)。Lambda 変換=配信前にレコードを加工。形式変換=JSON を Parquet/ORC へ。動的パーティショニング=内容に応じて S3 のパスを分け、Athena のクエリ効率を上げる。
- Data lake 階層(Sentinel)
- 大量データを長期・低コストで保管し、後からの探索に使う Sentinel のデータ保持階層。高頻度の検知/相互調査に使う高コストの Analytics 階層と使い分ける。KQL ジョブでバッチ的に探索する。
- Data Migration Assistant(DMA)
- SQL Server から Azure SQL 等への移行前評価ツール。互換性の問題や非推奨機能を検出し、移行先の推奨や機能パリティを確認する。2025-07-16 に提供終了(retired)となり、現在は Azure SQL 移行拡張機能や Azure Migrate 等が代替として推奨される。
- Database Migration Service(Google Cloud DMS)
- MySQL/PostgreSQL などを Cloud SQL や AlloyDB へ継続的レプリケーション付きで移行する Google のマネージドサービス。最小ダウンタイムのカットオーバーを支援する。
- database watcher
- Azure SQL の監視データを収集し一元ダッシュボードで可視化するマネージド機能。複数のデータベースをまたいだ性能監視に使う。
- Dataflow
- バッチとストリーミングの両方に対応するデータ処理パイプラインのサービス。
- Dataflow Gen2(データフロー Gen2)
- Power Query を使い、ノーコードでデータを取得・整形して宛先(レイクハウス/ウェアハウス等)へ書き出す変換ツール。少量〜中量の整形向き。
- Dataflows(データフロー)
- Power Query を使って外部ソースからデータを取得・整形し、Dataverse 等へ継続的に取り込む仕組み。繰り返しのデータ準備を自動化する。
- Dataform
- BigQuery 内の SQL ベースの変換(ELT)を、依存関係やバージョン管理とともに開発・運用できるサービス。
- Dataplane V2
- eBPF ベースで実装された GKE のネットワーキングデータプレーン。Kubernetes NetworkPolicy(Pod 間の L3/L4 通信制御)をカーネルレベルで高効率に強制し、フローログによる可視化も提供する。GKE 1.20 以降の新規クラスタで既定化が進んでおり、従来の iptables ベース実装より少ないオーバーヘッドで動く。
- Dataplex と Dataplex Catalog
- Dataplex は分散したデータ(レイク/ウェアハウス)を横断して品質・ガバナンスを一元管理するデータプラットフォーム。Dataplex Catalog はメタデータを発見・整理してデータの所在と意味を把握する。
- Dataproc
- 既存の Spark / Hadoop ワークロードをマネージドで実行するサービス。Dataflow(Beam)とは用途が異なる。
- Datastream
- ソースデータベースの継続的な変更を変更データキャプチャ(CDC)でストリーム複製するサーバーレスサービス。最小停止の一括 DB 移行は Database Migration Service。
- Dataverse business events
- 「注文確定」のような業務上の出来事をイベントとして発行し、購読側が反応できる仕組み。CRUD のテーブル操作イベントと別。
- Dataverse for Teams
- Microsoft Teams 内で使える簡易版の Dataverse。追加ライセンスなしでチーム向けにアプリ/フロー/ボットを作れる(容量や機能は制限あり)。
- Dataverse Web API
- OData v4 ベースの REST API で、任意の言語のクライアントから HTTP で Dataverse を操作する(Xrm.WebApi)。サーバーの Organization service と区別する。
- Dataverse のセキュリティ範囲(チーム/業務単位/行共有)
- Dataverse のアクセス スコープ。チーム(ユーザーのグループ)、業務単位(組織階層)でセキュリティロールをスコープし、行共有で個別レコードを例外的に共有する。
- Dataverse プラグイン
- Dataverse のイベント(作成/更新等)にサーバーサイドで同期/非同期にビジネスロジックを実行する拡張。client scripting(クライアント/フォーム UX)と区別する。
- Dataverse 検索
- 複数テーブルを横断して関連度順に結果を返す全文検索。モデル駆動型アプリや Power Pages で素早く目的のレコードを見つけられる。
- DAX Studio
- DAX クエリの実行・計測・トレースを行う外部ツール。サーバータイミングでストレージエンジン/フォーミュラエンジンの内訳を確認できる。
- DAX パフォーマンスの改善
- 遅い DAX を速くする取り組み。変数で再評価を避ける、イテレーターを減らす、フィルターを最適化する、スタースキーマ化するなど。
- DAX 変数(VAR)
- VAR で式の途中結果を変数に保持し RETURN で返す書き方。可読性が上がり、同じ計算の再評価を避けて性能も改善する。
- DAX(Data Analysis Expressions)
- セマンティックモデルでメジャーや計算列を書く式言語。行コンテキストとフィルターコンテキストで評価される。
- DB パラメータグループ
- DB エンジンの設定値(最大接続数・タイムアウト・文字コード等)をまとめて管理するテンプレート。動的パラメータは即時反映されるが、静的パラメータの変更はインスタンスの再起動が必要になる点が試験で問われやすい。
- DBMS(データベース管理システム)
- データの格納・検索・更新・排他制御・障害復旧などを一元管理するソフトウェア。アプリケーションから直接ファイルを操作させず、SQL などの標準インタフェースを介して整合性・永続性・同時実行制御を保証する。
- DBサーバー
- Web3層モデルの最下層で、データの永続化と管理を担うサーバー。AP サーバーからの問い合わせに応じてデータを読み書きする。
- DDoS 攻撃の種類(L3/L4 と L7)
- L3/L4 攻撃=大量パケットで回線/資源を飽和(SYN フラッド・リフレクション/増幅)→Shield/NLB/スクラビングで吸収。L7 攻撃=正規に見えるリクエストでアプリを枯渇→WAF のレートベースルールや Shield Advanced で防ぐ。層に応じた防御を重ねる。
- deadlock_timeout
- あるトランザクションがロック待ちになってからデッドロック検出処理を走らせるまでの待ち時間を定めるパラメータ。値を大きくすると検出処理の負荷は減るがデッドロック発覚が遅れ、小さくすると逆になる。
- default_statistics_target / effective_cache_size
- プランナに関わる主要パラメータ。default_statistics_target は ANALYZE が収集する統計の精度(MCV・ヒストグラムの分解能)を左右する既定値。effective_cache_size は OS のファイルシステムキャッシュも含めた実効的なキャッシュ規模の見積もりで、Index Scan の有利さの判断に影響する。
- Defender CSPM
- クラウドセキュリティ態勢管理。設定の弱点を推奨事項として提示し、攻撃パス分析でつながったリスク経路を可視化、シークレットスキャンでハードコードされた秘密を発見する事前の態勢管理。実行時の脅威検知(CWP)とは別の柱。
- Defender for Cloud DevOps セキュリティ
- GitHub・Azure DevOps・GitLab を Defender for Cloud に接続し、コードやパイプラインの構成ミス・シークレット露出・脆弱性を検出する。
- Defender for Containers
- コンテナワークロードの構成ミスと実行時リスク(不審なプロセス・既知の悪用など)を検知する Defender プラン。イメージの既知脆弱性スキャンと信頼イメージ許可(ACR)とは補完的に併用する。
- Defender for Databases
- Azure の各データベースサービスに脅威保護を提供し、SQL インジェクションの疑い・異常なログイン・機微データへの異常アクセスを検知する(旧 Advanced Threat Protection)。記録が役割の SQL 監査とは異なる。
- Defender for Key Vault
- Key Vault への異常なアクセスパターン(普段と異なる場所・大量取得など)を実行時に検知してアラートする脅威保護プラン。ハードコードされた秘密を事前に発見する Defender CSPM のシークレットスキャンとは役割が異なる。
- Defender for Servers
- VM の脆弱性スキャン(Defender 脆弱性管理)・EDR(Defender for Endpoint 統合)・エージェントレス スキャン・JIT VM アクセスを提供する。Azure Arc でオンプレや AWS/GCP のサーバーにも拡張できる。
- Defender 脆弱性の管理
- VM やコンテナの既知の脆弱性(CVE)を継続的に検出し、優先度付けと修復推奨を提示する機能。Defender for Servers/Containers に組み込まれる。
- DeletionPolicy(Retain/Snapshot)
- CloudFormation でスタック削除/リソース置換時に、そのリソースをどう扱うかを指定する属性。Retain=残す、Snapshot=スナップショットを取ってから削除、Delete=既定。DB やバケットの誤削除防止に使う。
- Delivery Optimization
- Windows Update やアプリのコンテンツを、インターネットや Microsoft のクラウドだけでなく、同一ネットワーク内・組織内の他デバイス(ピア)からも取得できるようにする Windows の帯域最適化機能。WAN 回線への負荷を減らし、拠点間の帯域が限られる環境でも更新の展開を高速化する。
- Delta テーブル(Delta 形式)
- Fabric のテーブルの既定フォーマット。Parquet にトランザクションログを足し、ACID・タイムトラベル・スキーマ管理を可能にする。OneLake のテーブルはこれで保存される。
- Dependabot
- 依存ライブラリの脆弱性を通知(alerts)し、修正/更新の PR を自動作成する機能。
- Dependabot アラートとセキュリティ更新
- Dependabot アラートは依存の既知脆弱性(Advisory/CVE)を通知。セキュリティ更新は安全な版へ上げる PR を自動作成。バージョン更新は脆弱性に関係なく定期的に最新化(両者は別物)。
- Dependency Review
- PR で追加/更新される依存の差分をマージ前に検査し、脆弱な依存や不許可ライセンスの混入をブロックするゲートベースの予防。必須チェックにできる。
- Deployment Manager
- Google Cloud のネイティブな Infrastructure as Code サービス(YAML/Jinja/Python テンプレート)。非推奨化され 2026-03-31 にサポート終了予定で、Terraform ベースの Infrastructure Manager などへの移行が推奨される。
- DevNet Sandbox
- Ciscoが開発者向けに無料で提供する検証環境。実機を用意せずにMeraki・Catalyst Center・ACI等のAPIやNETCONF/RESTCONFを試せる常設・予約制の環境が公開されており、Code Exchange(サンプルコード共有)・Learning Labs(学習コンテンツ)・API docsと合わせてDevNetの中心的なリソース群を成す。
- DevOps
- 開発(Development)と運用(Operations)が密接に連携し、自動化やCI/CDを活用して、より速く継続的にソフトウェアを提供しようとする考え方・文化。
- DevSecOps
- セキュリティ検証をリリース後の後工程ではなく開発の初期段階から組み込む考え方(シフトレフト)。コードレビューや自動脆弱性スキャンをCI/CDパイプラインに組み込み、脆弱性を安価な早い段階で見つけて修正する。
- DHCP
- ネットワークに接続した機器へIPアドレスなどの通信に必要な設定情報を自動的に割り当てるプロトコル。管理者が機器ごとに手動でIPアドレスを設定する手間を省ける。
- DHCPスコープ設計
- DHCPサーバが払い出すIPアドレス範囲(スコープ)と、除外範囲・リース期間・付随オプション(デフォルトゲートウェイ、DNSサーバなど)をサブネットごとに定義する設計。固定割当対象や他用途で予約すべきアドレスを除外範囲として切り分け、同時接続端末数とリース期間のバランスでアドレス枯渇を防ぐ点が設計上の要点となる。
- DHCPスタベーション
- 攻撃者が大量の偽装したMACアドレスでDHCPサーバーにIPアドレスを要求し尽くし、正規の端末にアドレスを払い出せなくするDoS攻撃。対策として、スイッチのポートごとにDHCP要求数を制限したりDHCPスヌーピングを使う。
- DHCPスヌーピング
- スイッチのポートを信頼済み(正規のDHCPサーバ接続)と非信頼(一般端末)に分類し、非信頼ポートからのDHCPサーバ応答(OFFER/ACK)を破棄する機能。不正なDHCPサーバによる偽のゲートウェイ配布(中間者攻撃)を防止する。
- DHCPリレーエージェント
- DHCPのDISCOVER等はブロードキャストでルータを越えないため、DHCPサーバが無いセグメントのクライアントが別セグメントのサーバを使えるよう、各セグメントのルータ(デフォルトゲートウェイ)に設定する中継機能(IPヘルパー)。受信したDHCPブロードキャストを指定サーバへユニキャストで中継する。1台のサーバで複数サブネットに配布できる。
- DHE/ECDHE(一時鍵交換)
- Diffie-Hellman鍵交換をセッションごとに一時鍵ペアで行う方式(ECDHEは楕円曲線版)。長期鍵を鍵合意に使わないため前方秘匿性(PFS)を実現できる。静的RSA鍵交換に代わりTLS1.3の基本方式となっている。
- Direct Connect vs VPN
- オンプレ接続の比較。Site-to-Site VPN=インターネット経由で安価・即時だが帯域/遅延が不安定。Direct Connect=専用線で安定・低遅延・高帯域だが構築に時間とコスト。重要回線は DX+VPN をバックアップに組み合わせる。
- Direct Connect の構成(VIF / DX Gateway / LAG)
- Direct Connect 上で論理接続を切る単位が仮想インターフェイス(VIF)。プライベート VIF=VPC へ、パブリック VIF=AWS パブリックサービスへ、トランジット VIF=Transit Gateway へ接続する。Direct Connect Gateway は複数リージョン/複数 VPC をまとめて接続し、LAG(リンクアグリゲーション)は複数の物理回線を束ねて帯域を増やす(冗長性は別途、複数ロケーションで確保)。
- Direct Connect の復元性(BFD)
- 本番には複数ロケーション・複数デバイスで冗長化する高/最大復元性モデルを使う。BFD(双方向フォワーディング検出)で障害検出を高速化し、フェイルオーバー時間を短縮する。
- Direct Lake
- Power BI が OneLake の Delta テーブルを、インポートも DirectQuery もせずに直接・高速に読むセマンティックモデルのモード。非対応機能では DirectQuery にフォールバックする。
- Direct Lake on OneLake
- Direct Lake の実行方式のうち、OneLake 上の Delta テーブルの列データを SQL 分析エンドポイントを介さず参照し、クエリ実行時にオンデマンドで VertiPaq エンジン用にメモリへトランスコードする経路。Direct Lake on SQL と対比される。機能面の制約や既定として使われるかどうかはモデル作成時の状況(フォールバック条件・サポートされる機能範囲)に依存し、一律に「制約が少なく既定で高性能」とは言い切れない。
- Direct Lake のフォールバック
- Direct Lake が未対応の状況(一部の機能や上限超過)で、自動的に DirectQuery に切り替わる挙動。性能低下の原因になるため回避設計が問われる。
- DirectLake モード
- Microsoft Fabric のレイクハウス/OneLake 上の Parquet を直接読み込む Power BI のストレージモード。Import 並みの性能を更新なしで大規模データに対して得られる。Import(取り込み)・DirectQuery(ソース問い合わせ)と区別する。
- DirectQuery モード
- 元のデータソースへ都度クエリを投げる方式。常に最新だが、ソース性能に依存し概してインポートより遅い。
- DLP ポリシー(Power Platform)
- コネクタを業務データ/非業務データ/ブロックに分類し、機微なデータが許可されない経路で混在・流出しないよう統制する仕組み。環境や全社に適用する。
- DLP ルール(Workspace)
- Drive や Gmail で機微情報の共有/送信を検知し、警告またはブロックするルール。検出条件(定義済み/カスタム)とアクション(警告・ブロック・監査)を設定する。
- DLP(Data Loss Prevention)
- メール送信・USBメモリへのコピー・クラウドストレージへのアップロードなどを監視し、機密情報や個人情報のパターンに合致する情報の外部持ち出しを検知・警告・ブロックする仕組み。内部不正や誤操作による情報漏えいの防止に用いる。
- DMA(Direct Memory Access)
- CPUを介さず、専用のDMAコントローラがメモリと周辺装置間のデータ転送を直接行う方式。CPUは転送開始を指示した後は他の処理を継続でき、大量データの転送でCPU負荷を大幅に下げられる。一方でDMA転送中はメモリバスを占有するため、CPUのメモリアクセスと競合し実行時間がばらつく要因にもなる。
- DMZ(非武装地帯)
- 外部ネットワークと内部ネットワークの間に設ける中間的なセグメント。外部に公開するWebサーバーやメールサーバーをここに置き、内部ネットワークが直接外部からアクセスされないようにする。
- DNS
- ドメイン名(例:example.com)とIPアドレスを相互に変換する分散型のディレクトリサービス。ポート53で動作し、人が読める名前で通信先を指定できるようにする。名前解決の失敗はアプリ接続性の障害としてよく現れ、正しいIPへの到達可否とは別に切り分けるべき原因になる。
- DNS / 名前解決(レコードタイプ)
- ドメイン名を IP へ変換する仕組み。主なレコード=A(IPv4)/AAAA(IPv6)/CNAME(別名・頂点不可)/MX(メール)/TXT(検証)/NS(委任)。AWS の Alias レコードは頂点でも AWS リソースを指せる CNAME 代替。TTL でキャッシュ時間を制御。
- DNS クライアント設定(host/dig/resolv.conf)
- 名前解決の設定と確認。/etc/resolv.conf の nameserver が問い合わせ先 DNS サーバー、/etc/nsswitch.conf が参照順序(通例 files→dns)、/etc/hosts が静的対応表。host/dig は DNS へ直接問い合わせ(dig は @ でサーバー指定)、getent は nsswitch の順序どおり(/etc/hosts 込み)に解決する。
- DNS(ドメインネームシステム)
- 人間が覚えやすいドメイン名(例:example.com)とIPアドレスを対応付ける仕組み。利用者がドメイン名を入力するだけで、対応するサーバーのIPアドレスへ自動的に到達できるようにする。
- DNSキャッシュポイズニング
- キャッシュDNSサーバに偽の名前解決結果を注入し、利用者を攻撃者の用意した偽サイトへ誘導する攻撃。正規の権威DNSサーバからの応答より先に、推測したトランザクションIDや送信元ポート番号を持つ偽の応答を送りつけてキャッシュさせる。対策はソースポートのランダム化やトランザクションIDのランダム化、DNSSECによる応答の署名検証。
- DNSの委任とゾーン
- ゾーンはDNSの名前空間のうち1つの権威サーバ群が管理を担う範囲。委任は親ゾーンのネームサーバが子ドメインの管理権限をNSレコードによって別のネームサーバへ移譲する仕組みで、これにより階層的な分散管理が実現される。委任先が権威を持つゾーンはサブゾーンとして独立する。
- DNSリソースレコードと逆引き
- DNSのゾーンに登録する情報。A/AAAA(ホスト名→IP)・MX(メール配送先+プリファレンス値)・CNAME(別名)・NS(委譲)・PTR(IP→ホスト名の逆引き)・TXT(SPF等)などがある。逆引きはIPアドレスを逆順にしたin-addr.arpa(IPv6はip6.arpa)ゾーンにPTRレコードを置き、そのIPブロックの逆引きゾーン委譲を受けて実現する。
- Docker レジストリ
- Docker イメージを保管・配布するサーバー。Docker Hub が既定のパブリックレジストリで、docker pull/docker push でイメージを取得・登録する。組織はプライベートレジストリを独自運用することもできる。
- docker(コンテナランタイム)
- コンテナを作成・起動・停止するランタイム/ツール。docker run でイメージから起動、docker start/docker stop で既存コンテナを操作する。
- Dockerfile
- Dockerはコンテナを作成・実行するための代表的なプラットフォーム。Dockerfileはコンテナイメージの作り方を記述するテキストファイルで、FROM(ベースイメージ指定)・RUN(ビルド時コマンド実行)・COPY(ファイル配置)・CMD(起動時コマンド)・EXPOSE(公開ポート)等の命令を積み重ねてイメージを定義し、docker buildでイメージ化、docker runで実行する。
- Document AI
- 請求書や契約書などの文書から金額・日付などの情報を抽出し、文書処理を自動化するサービス。
- Document Intelligence カスタム/構成モデル
- 独自フォームを学習するカスタムモデル(テンプレート型/ニューラル型)と、複数のカスタムモデルを束ねて自動で振り分ける構成モデル。
- Document Intelligence プレビルト/レイアウトモデル
- 請求書・領収書・身分証など一般的な文書を学習なしで抽出するプレビルトモデルと、表・選択マーク・構造を抽出するレイアウトモデル。
- DORA メトリクス
- デリバリーパフォーマンスの 4 指標。スピード=デプロイ頻度・変更のリードタイム、安定性=変更失敗率・MTTR(平均復旧時間)。優れた DevOps はこの 4 つを同時に高める(速さと安定性は両立する)。
- DORA(DHCPの4ウェイメッセージ)
- DHCPがIPアドレスを割り当てる際の4段階のメッセージ交換:クライアントがブロードキャストするDiscover、サーバが提案を返すOffer、クライアントが希望を明示するRequest、サーバが確定するAcknowledgeの頭文字。既存リースの更新時はDiscover/Offerを省いたRequest/ACKのみで済む場合がある。
- DoS・DDoS
- DoS(Denial of Service)は単一の攻撃元からサービスを応答不能に陥らせる攻撃。DDoS(Distributed DoS)は多数の踏み台(ボットネット等)から同時に攻撃を仕掛けるため送信元が分散し、単純な送信元ブロックでは防げない点が対応を難しくする。
- DoS攻撃/DDoS攻撃
- 大量のリクエストや不正なパケットを送りつけてサーバやネットワークを過負荷にし、正規の利用者がサービスを使えなくする攻撃(DoS=サービス妨害)。DDoS(分散型DoS)は、マルウェアに感染させた多数の機器(ボットネット)から一斉に攻撃を行うため送信元が分散し、単純な送信元遮断では防ぎにくい。情報の機密性ではなく可用性を損なう攻撃である。
- DoS攻撃/DDoS攻撃とSYN Flood攻撃
- DoS攻撃は単一の攻撃元から大量の要求や不正なパケットを送りつけ、サービスを提供不能にする攻撃。DDoS攻撃は多数の踏み台(ボットネット等)から同時に行う分散型のDoS攻撃で、発信元が分散するため遮断が難しい。SYN Flood攻撃はTCPの3ウェイハンドシェイクを悪用し、SYNパケットだけを大量送信してACKを返さず、サーバ側に大量の接続待ち(半接続)状態を残してリソースを枯渇させるDoS攻撃の代表例。SYN Cookieなどで対策する。
- dpkg(deb パッケージ直接操作)
- apt の下で働く低レベルツール。deb ファイルを直接扱う(-i 導入・-r 削除・-P 設定ごと削除=purge)。依存関係は解決しない。照会は -l 一覧・-L パッケージ→ファイル・-S ファイル→パッケージ。dpkg-reconfigure で対話設定をやり直す。
- DR テスト
- 災害復旧計画が実際に機能するかを検証する取り組み。バックアップからのリストア確認やフェイルオーバー訓練を通じて、目標復旧時間(RTO)と目標復旧時点(RPO)を実測し、計画と現実の乖離を洗い出して改善する。定期的に実施しないと計画は形骸化しやすい。
- DR 戦略(4段階)
- バックアップ&リストア(安・遅)→パイロットライト→ウォームスタンバイ→マルチサイト(高・速)。RTO/RPO が短いほど高コスト。クロスリージョンレプリケーション+Route 53 フェイルオーバーで広域障害に備える。
- DR 戦略(バックアップ/ウォーム/ホットスタンバイ)
- RTO/RPO が緩ければ安価なバックアップ&リストア、厳しければウォームスタンバイ(縮小構成を待機)やホットスタンバイ(フル稼働の冗長)を選ぶ。RTO=復旧時間、RPO=許容データ損失。
- DR/BDR/DROTHER(OSPF)
- マルチアクセス網(イーサネット等)でOSPFが全ルータ間のフルメッシュな隣接を避けるための仕組み。優先度が最も高いルータがDR(代表ルータ)、次点がBDR(バックアップ代表ルータ)に選出され、他の全ルータ(DROTHER)はDR/BDRとのみフル隣接を形成し、経路情報はDRを介して間接的に交換される。これによりLSA交換の量を大幅に削減できる。
- DRP(災害復旧計画)
- 地震やサイバー攻撃によるシステム停止などの緊急事態から、ITシステムを目標時間内に復旧させるための具体的な手順を定めた計画(Disaster Recovery Plan)。事業全体の継続を扱うBCPの下位に位置し、バックアップからの復元手順やRTO/RPOの達成手段を規定する。
- DSCPとPHB
- DSCP(Differentiated Services Code Point)はIPヘッダのフィールドにパケットの優先度クラスを刻印する仕組みで、EF(音声等の最優先転送)・AF(保証転送、クラスとドロップ優先度で細分)・CS(旧IP優先度との互換)等の値がある。各ネットワーク機器はDSCP値に応じた転送挙動(PHB=Per-Hop Behavior)をホップごとに独立して適用し、送信元から宛先まで一貫したQoSを実現する。
- DSP(デジタル信号処理プロセッサ)
- 積和演算(MAC演算)をハードウェアで高速に繰り返し実行できるよう最適化されたプロセッサ。音声/画像/センサ信号のフィルタリングやFFTなど、リアルタイム性が要求される数値演算処理に用いられる。汎用MCUでは間に合わない演算量を、専用パイプラインと並列積和器で処理時間内に収める設計判断が要となる。
- DSSE-KMS(二重レイヤー暗号化)
- S3オブジェクトに2つの独立した暗号化レイヤーをKMS鍵で適用するサーバーサイド暗号化方式。FIPS 140-2やITAR等、単一レイヤーの暗号化では満たせない高い保証要件(二重暗号化義務)を持つ規制業界向け。通常のSSE-KMSより処理コストは増える。
- DTP(Dynamic Trunking Protocol)
- 隣接スイッチのポート同士でトランクの自動ネゴシエーションを行うCisco独自プロトコル。利便性がある一方、意図せずトランクが成立するとVLANホッピングの糸口になるため、セキュリティ上は不要なポートでDTPを無効化(nonegotiate)するのが推奨される。
- Durable Functions
- ステートフルなワークフローを関数で書く拡張。オーケストレーター関数が処理の流れ(関数チェーン・ファンアウト/イン・人による承認など)を管理する。
- DVFS(動的電圧・周波数制御)
- 処理負荷に応じてプロセッサの動作クロック周波数と供給電圧を動的に変化させ、必要な性能を確保しつつ消費電力を抑える省電力技術。消費電力は電圧の2乗と周波数に概ね比例するため、負荷が低い場面で周波数・電圧を下げる効果は大きく、バッテリ駆動の組込み機器の電力設計で重要な手法となる。
- DX(デジタルトランスフォーメーション)
- データとデジタル技術を活用して、製品・サービス・ビジネスモデルや組織・企業文化を変革し、競争上の優位性を確立すること。単なるIT化(デジタイゼーション)とは目的が異なる。
- Dynamic Workload Scheduler
- GPU/TPU など希少なアクセラレータ容量の確保をスケジュールするサービス。需要が高いリソースを計画的に取得する。
- DynamoDB Accelerator(DAX)
- DynamoDB 専用のインメモリキャッシュ。読み取りをマイクロ秒級まで高速化し、読み取り負荷を肩代わりする。アプリ側のコード変更を最小に抑えられる。
- DynamoDB の TTL(自動失効)
- 項目に有効期限のタイムスタンプ属性を設け、期限切れの項目を自動で削除する機能(書き込み容量を消費しない)。セッションやログ等の一時データを自動掃除し、ストレージコストを抑える。削除は DynamoDB Streams にも流せる。
- DynamoDB のキャパシティモード(オンデマンド/プロビジョンド+Auto Scaling)
- オンデマンド=容量管理不要で需要に自動追従(予測困難な負荷・使った分だけ課金)。プロビジョンド=RCU/WCU を設定し、Auto Scaling で利用率の目標に追従させる(予測可能な負荷で割安、予約キャパシティで更に割引)。負荷特性で選ぶ。
- DynamoDB の書き込み制御(条件付き/トランザクション)
- 条件付き書き込みで競合を防ぎ、楽観的ロック(バージョン番号)で上書きを検出。複数項目の整合性はトランザクション(TransactWriteItems)で担保し、読み取りは Query(キー)と Scan(全走査)を使い分ける。
- DynamoDB の設計機能(GSI/DAX/Global Tables)
- グローバルセカンダリインデックス(GSI)で別キーの検索を、DAX でマイクロ秒のキャッシュを、Global Tables でマルチリージョン能動複製を、Streams で変更イベントを得る。容量はオンデマンドかプロビジョンド。
- DynamoDB の容量と TTL
- 容量はオンデマンド(自動・従量)かプロビジョンド(RCU/WCU・Auto Scaling)。TTL で期限切れ項目を自動削除し、PartiQL で SQL 風にアクセスできる。スロットリングは指数バックオフで再試行する。
- DynamoDB の容量挙動(ホットパーティション/適応キャパシティ)
- アクセスが特定キーに偏るとホットパーティションでスロットリングが起きる。適応キャパシティが偏りを自動で吸収し、バーストキャパシティが短時間の超過を許容する。設計の基本は高カーディナリティなパーティションキーで負荷を分散すること。
- E-R図(実体関連図)
- データベース設計において、実体(エンティティ)とその間の関連(リレーションシップ)を図で表現する概念モデリング手法。実体間の多重度(1対1・1対多・多対多)を明示し、論理データベース設計や正規化の前段階として用いられる。
- e-ビジネスとEC(電子商取引)
- e-ビジネスはインターネットを活用した事業活動全般を指す。その中核であるEC(電子商取引)は、ネットワーク上で商品・サービスを売買する取引で、企業間のBtoB、企業対消費者のBtoC、消費者間のCtoCなどに分類される。
- EAI(エンタープライズアプリケーション統合)
- 企業内に散在する異種のアプリケーションやシステムを連携させ、データやプロセスを統合する仕組み・製品群。多数のシステムをハブ&スポーク型で中央のハブに接続してアダプタで差異を吸収し、個別の点対点接続の複雑化を避けるのが典型構成である。システムアーキテクトはEAIを用いて既存システムを大きく作り替えずに相互連携させ、データの二重入力や不整合を解消する。
- eBGP(外部BGP)
- 異なるAS(自律システム)間でルータが直接接続してピアを組むBGPの形態。管理者距離は既定20でIGP由来の経路より優先される。ベストパス選択では複数の経路属性を優先度順に比較し、代表的にはWeight→ローカルプリファレンス→自発生成経路→AS_PATH長の短さ→オリジン種別→MED→eBGP経路の優先→IGPメトリックの小ささの順に絞り込む。
- EBS スナップショット
- EBS ボリュームを S3 に増分バックアップする仕組み(2回目以降は差分のみ保存)。別 AZ/リージョンへコピーや AMI 化、共有が可能。高速スナップショット復元(FSR)で復元直後の I/O 遅延を解消できる。Data Lifecycle Manager で自動化する。
- EBS スナップショット共有
- EBS スナップショットを他の AWS アカウントと共有する機能。暗号化済みスナップショットを共有する場合は、スナップショット自体の共有設定に加えて、暗号化に使ったカスタマー管理キー(CMK)の鍵ポリシーで相手アカウントに使用権限を付与する必要がある。
- EBS ボリュームタイプ(gp3/io2/st1/sc1)
- 汎用 SSD の gp3(IOPS/スループットを独立設定)、高耐久・高 IOPS の io2/io2 Block Express、スループット最適化 HDD の st1、コールド HDD の sc1 をワークロードで選ぶ。
- EBS 暗号化
- EBS ボリュームを AWS KMS の鍵で保管時暗号化する機能。暗号化されたボリュームから作成したスナップショットや AMI も暗号化が引き継がれ、アカウント/リージョン単位で既定の暗号化を強制することもできる。既存の未暗号化ボリュームは直接変換できず、スナップショット経由でのコピーが必要。
- EC2 Fleet
- 1回のリクエストで複数のインスタンスタイプ・購入オプション(オンデマンド/リザーブド/スポット)・AZ を横断し、目標容量を満たすインスタンス群を起動する機能。オンデマンドとスポットを組み合わせて起動できるのが Spot Fleet との違い。リクエストタイプは instant(同期・一回限り)/request(非同期・一回限り)/maintain(容量を維持し中断分を自動補充)の3種で、既定は maintain。
- EC2 インスタンスファミリー
- 用途別の EC2 タイプ群。汎用(T/M:バランス、T はバースト)、コンピューティング最適化(C:高 CPU)、メモリ最適化(R/X:大容量メモリ)、ストレージ最適化(I/D:高速ローカル)、高速コンピューティング(P/G:GPU)。ワークロードに合わせて選ぶ。
- EC2 ステータスチェックと自動回復
- システムステータスチェック=AWS 側のインフラ障害(ホスト/ネットワーク)。インスタンスステータスチェック=OS/設定など内部要因。アタッチドEBSステータスチェックもある。CloudWatch アラームの EC2 アクション(recover/reboot/stop/terminate)で自動回復を設定する。
- EC2 ハイバネーション
- メモリ(RAM)の内容を EBS に保存して停止し、再開時に状態を復元する機能。OS やアプリの再起動なしに作業状態を引き継げる。長い初期化を伴うワークロードの起動短縮に使う。
- ECMP(等コストマルチパス)
- 同一メトリック(等コスト)を持つ複数の経路にトラフィックを均等に分散する一般的なルーティング手法。特定ベンダーに限らず広く使われる概念で、代表的な適用例が AWS Transit Gateway に接続した複数の VPN トンネル間での分散である。単一トンネルの帯域上限(約 1.25 Gbps)を超えたい場合、Transit Gateway では複数トンネルを束ねて ECMP で分散することで合計スループットを引き上げられる。
- ECS タスクロール
- コンテナ内で動くアプリケーションコードが、S3やDynamoDB等のAWS APIを呼び出すために引き受けるIAMロール。アプリの実処理に必要な権限だけを与える最小特権の対象で、タスク定義のtaskRoleArnで指定する。
- ECS タスク実行ロール
- ECSエージェント自体がコンテナを起動するために使うIAMロール。ECRからイメージを取得し、CloudWatch Logsへログを送信し、Secrets Manager/SSM Parameter Storeから環境変数用の機密値を取得する権限を持つ。タスクロールとは別物で、アプリコードには渡らない。
- EDF(最早期限優先スケジューリング)
- デッドラインが最も近いタスクに動的に最高優先度を与えるスケジューリング方式。固定優先度のレートモノトニックと異なり優先度が実行時に変動する動的優先度方式で、単一プロセッサでは利用率100%までスケジュール可能という点で理論上より高いCPU利用率を達成できるが、実装の複雑さと過負荷時の予測困難性がトレードオフとなる。
- EDI(電子データ交換)
- 受発注書・請求書などの商取引データを、あらかじめ定めた形式でコンピュータ間で電子的にやり取りする仕組み。紙の書類より処理を迅速化・省力化できる。
- eDiscovery(電子証拠開示)
- 訴訟や調査のために関連コンテンツを検索・保全(ホールド)・収集・書き出しする仕組み。
- Edit Mode
- 自然言語の指示で複数ファイルにまたがる変更を提案・適用するモード。どこを直すかの範囲は利用者が示す。
- EDR ブロック モード
- サードパーティのアンチウイルス製品が受動モード(passive mode)で稼働しているデバイスでも、Defender for Endpoint の EDR が検出した悪意ある成果物を事後的にブロック・修復する機能。他社 AV をメインに使う環境でも EDR の検出力を無駄にしない保険として働く。
- EDR(Endpoint Detection and Response)
- PCやサーバーなどのエンドポイント上での挙動を常時監視・記録し、侵入後の不審な振る舞い(プロセス起動・通信・ファイル改変など)を検知して隔離や調査を行う仕組み。入口対策であるアンチウイルス(既知パターンの検出)に対し、侵入されることを前提にした事後対応・可視化を担う。
- EEM(Embedded Event Manager)
- 機器上で発生する事象を検知し、それに応じた処理を自動実行するCisco IOSの仕組み。appletの中でevent(syslogメッセージのパターン一致・タイマー・CLIコマンド実行等のトリガー)を定義し、それが成立した際に実行するaction(別のCLI実行・通知送信等)を組み合わせることで、外部ツールなしに機器単体でトラブルシュートや設定変更を自動化できる。
- EFS のモード(パフォーマンス/スループット/ストレージクラス)
- EFS の設定軸。パフォーマンスモード=汎用(低遅延)/最大 I/O(高並列)。スループットモード=バースト/拡張(Elastic・需要に自動追従)/プロビジョンド。ストレージクラスは標準/低頻度アクセス(IA)で、ライフサイクル管理により自動階層化しコストを下げる。
- EIGRP(Enhanced Interior Gateway Routing Protocol)
- 帯域幅と遅延を主なメトリックに使う高度ディスタンスベクタ型プロトコルで、DUAL(Diffusing Update Algorithm)アルゴリズムによりループフリーな経路計算と高速収束を実現する。既定では最小コストの経路のみを使うが、variance係数を設定すると条件を満たす複数の不等コスト経路へも負荷分散できる。管理者距離(AD)は既定90でOSPFの110より優先される。
- Elastic IP と配置グループ
- Elastic IP は付け替え可能な固定パブリック IP。配置グループはインスタンスの物理配置を制御し、クラスター(低遅延)・スプレッド(障害分離)・パーティション(大規模分散)から選ぶ。
- Elastic Jobs
- Azure SQL Database 向けの自動化。ジョブエージェントとジョブ DB を使い、ターゲットグループで複数 DB に T-SQL を並列実行する。
- Elastic Load Balancing(ELB)
- トラフィックを複数のインスタンス/AZの正常な宛先へ分散する。高可用性の定番。
- Elastic Network Interface(ENI)
- 仮想ネットワークカード。プライベート IP・Elastic IP・セキュリティグループ・MAC を持ち、インスタンス間で付け替え(フェイルオーバー)できる。複数 ENI で多重ホーミングや管理/データ系の分離を行う。
- ElastiCache(Redis / Memcached)
- インメモリキャッシュ。Redis OSS(および 2024 年以降の推奨エンジン Valkey)はレプリケーション・永続化・Pub/Sub・ソート等の高機能、Memcached は単純でマルチスレッドな水平スケール。用途で選ぶ。
- ELT(抽出・格納・変換)
- データ統合パターンの一つ。ソースから抽出した生データをまず格納先(データウェアハウス/レイク)へロードし、格納先のコンピュート能力を使って後から変換する。クラウド型DWHの並列処理性能向上で普及し、生データを残せる柔軟性が利点。
- Endpoint Analytics
- device health scores(起動時間・バッテリー・ドライバー等の健全性)、startup performance(起動時間の内訳)、application reliability(アプリのクラッシュ・応答なし頻度)などの指標でエンドポイントの性能・信頼性とユーザー体験を可視化する Intune の分析機能。可視化に特化しており、検出した問題を自動で直接修復するわけではない。
- Endpoint DLP
- Windows/macOS のデバイス上で機密データのコピー(USB)・印刷・クラウドへのアップロード・クリップボードなどの操作を制御する DLP。クラウド ワークロードの DLP ポリシーとは別。
- Endpoint Privilege Management(EPM)
- Intune Suite のアドオン。標準ユーザーに常時管理者権限を与えず、特定の操作のときだけ一時的に昇格させる(最小特権)。
- Enterprise Managed Users(EMU)
- 企業が自社の ID 基盤(IdP)で一元管理する専用ユーザー。個人アカウントとは切り離される。
- Enterprise チーム
- Enterprise 配下の複数 Organization にまたがってメンバーシップ・ロール・ポリシー(ガバナンス)を一元管理できる上位のチーム概念。一度定義したチームを多数の Organization に割り当てられる。ネストや親権限の継承は Organization レベルのチームの機能で、Enterprise チームには当てはまらない。
- Entra ID ガバナンス
- 適切な人が適切なリソースに適切な期間だけアクセスできるよう統制する。エンタイトルメント管理(アクセスパッケージ)、アクセスレビュー、Privileged Identity Management(PIM)、ライフサイクルワークフローを含む。
- Entra の ID の種類
- Microsoft Entra が管理する ID の種類。ユーザー(メンバー/ゲスト)、グループ、デバイス、そしてアプリやサービスを表すワークロード ID(サービスプリンシパル/マネージド ID)がある。
- Entra のユーザーとグループ
- メンバー/ゲストユーザーと、割り当て済み/動的グループを管理する。割り当て済みグループ=手動でメンバーを追加。動的グループ=属性ルールでメンバーを自動決定(手動追加は不可)。大量のユーザー作成/編集は一括操作(CSV インポート等)で別途行う。ゲストは招待で追加。
- env:(環境変数)
- ワークフロー/ジョブ/ステップの各レベルに環境変数を定義するキー。狭いスコープが優先される。
- EPSS(Exploit Prediction Scoring System)
- 脆弱性が実際に悪用される確率を推定するスコア。深刻度(CVSS)と組み合わせて「深刻かつ悪用されやすい」ものを優先するために使う。
- ERP(企業資源計画)
- 会計・人事・生産・販売などの基幹業務を統合的に管理し、経営資源(ヒト・モノ・カネ・情報)を全社的に最適配分するための考え方・パッケージソフトウェア。
- Error Reporting
- アプリのエラーを自動で集約・グルーピングし、発生頻度や新規発生を可視化・通知するサービス。生ログを目視するより影響の大きいエラーを優先しやすい。
- ESB(エンタープライズサービスバス)
- サービス指向アーキテクチャ(SOA)において、サービス間の連携を「バス」上のメッセージのルーティング・プロトコル/データ形式の変換・仲介によって取り持つ基盤。各サービスはバスを介して疎結合に通信するため、接続の組合せ数を抑え、サービスの追加・変更の影響を局所化できる。システムアーキテクトはESBを用いて多数のサービスを標準化された方式で疎結合に統合する。
- ESGとSDGs(経営)
- ESGは環境(Environment)・社会(Social)・ガバナンス(Governance)の3要素を重視する経営・投資の考え方で、企業の非財務的な持続可能性を評価する観点として投資家からも注目される。SDGs(持続可能な開発目標)は国連が採択した2030年までの17の目標群で、企業はSDGsへの貢献を経営戦略・事業戦略に組み込むことで、社会的責任(CSR)を超えた新たな事業機会の創出や長期的な企業価値向上につなげることが期待される。
- ESP(EFI システムパーティション)
- UEFI ブートでブートローダーを置く FAT 形式の専用パーティション。/boot/efi にマウントされる。
- ETag による楽観的同時実行制御
- 読み取り時の ETag と If-Match で、値が変更されていない場合だけ更新して競合上書きを防ぐ仕組み。ETag が一致しないと 412 が返り、再読込してリトライする。
- ETC(残作業コスト見積り)
- 現時点から完了までに必要な残りの作業に対するコスト見積り。現在のパフォーマンス傾向が今後も続くと仮定する場合は ETC = (BAC − EV) / CPI で算出し、EACの構成要素として資金計画の見直しに使う。
- EtherChannel
- 複数の物理スイッチポートを1つの論理リンクとして束ねるCiscoの実装名称で、束ねる制御にLACP(標準規格)またはPAgP(Cisco独自)のいずれかを使う。STPからは1本の論理リンクとして見えるため、リンク単位でのブロッキングを避けつつ帯域と冗長性を得られる。
- ETL(抽出・変換・格納)
- データ統合パターンの一つ。ソースからデータを抽出し、格納先に入れる前に変換(クレンジング・整形・集計)を行う。変換用の別コンピュート(サーバーやマネージドサービス)を要するが、格納先には整った形のデータだけが入る。
- EV(出来高実績値)
- 実際に完了した作業の量を、承認済み予算で評価した値。「完了した作業にいくらの価値があったか」を表し、PV・ACと組み合わせてSV・CV・SPI・CPIなどすべてのEVM指標を算出する中心的な値である。
- Event Threat Detection
- Security Command Center の組み込み検出で、Cloud Audit Logs(管理操作/データアクセス)等から既知の脅威(不審ログイン/権限昇格など)を検出する。クラウド固有 IOC はカスタム検出(カスタムディテクター)で補う。
- Event Viewer
- Windowsに標準搭載された、システム・セキュリティ・アプリケーションの各種イベントログを閲覧するツール。ログイン失敗の連続やサービスの異常終了など、通常と異なる挙動の痕跡を確認するのに使う。
- Eventarc
- Pub/Sub や Cloud Storage の変更など多様なイベント源からのイベントを Cloud Run / Cloud Functions へ統一的に配送する仕組み。
- EventBridge Pipes
- ソース(SQS・Kinesis・DynamoDB Streams など)とターゲットをポイントツーポイントで直結するパイプ。間にフィルタリング・エンリッチメント(Lambda 等での加工)・変換ステップを挟めるため、統合ロジックのために別途 Lambda を書かずに済むことが多い。
- EventBridge Scheduler
- cron・レート・一回限りのスケジュールを大規模かつタイムゾーン対応で実行できる EventBridge の機能。数百万単位のスケジュールを個別管理でき、旧来の CloudWatch Events ルールによるスケジュール実行の後継として位置づけられる。
- EventBridge アーカイブ
- イベントバスを通過したイベントを、指定した条件に一致するものだけ(または全件)保存しておく機能。障害復旧やデバッグのため過去のイベントを後からリプレイする前提となるストレージで、保持期間を無期限または日数指定で設定できる。
- EventBridge のクロスアカウント連携
- あるアカウントのイベントバスから別アカウントのバスへイベントを転送し、組織横断のイベント駆動を実現する。リソースベースポリシーで送信元を許可する。集中監査やセキュリティイベントの集約に使う。
- EventBridge ルール
- イベントパターン(発生元・内容で一致条件を定義)またはスケジュールに一致したイベントを、1つ以上のターゲット(Lambda・SQS・Step Functions 等)へ配信する規則。1つのルールに複数ターゲットを設定でき、配信失敗時の再試行やデッドレターキューへの退避も設定できる。
- Eventhouse(KQL データベース)
- Real-Time Intelligence で大量のイベント/時系列データを格納・分析するストア。中に KQL データベースを持ち、KQL で高速クエリする。
- Eventstream(イベントストリーム)
- イベント(IoT・ログ・キュー等)をノーコードで取り込み、変換して Eventhouse やレイクハウスへ送るストリーミングのパイプライン。
- EVM(出来高管理)
- プロジェクトの進捗とコストを金額換算した指標で管理する手法。計画値(PV)・出来高(EV)・実コスト(AC)から、コスト差異(CV)やスケジュール差異(SV)を算出し、遅延やコスト超過を定量的に把握する。
- Exchange Online
- メールとカレンダーを提供するクラウドサービス(メールボックスのホスティング)。Outlook はこれを使うクライアント。
- Exchange 管理センター
- Exchange Online のメール関連オブジェクトを構成する専用管理センター。メールボックスや配布リスト(複数の受信者へ一斉配信するグループ)を管理する。
- ExecuteMultiple(一括要求)
- 多数の作成/更新操作を 1 回の要求にまとめて性能を上げる仕組み(ExecuteMultipleRequest)。
- EXPLAIN / EXPLAIN ANALYZE
- プランナが選んだ実行計画を可視化するコマンド。EXPLAIN は計画のみ表示し実際にはクエリを実行しない(見積もり値のみ)。EXPLAIN ANALYZE は実際にクエリを実行し、実測の行数・所要時間も併記するため、見積もり(estimated rows)と実測(actual rows)の乖離から統計の陳腐化などを診断できる。
- ExpressRoute
- インターネットを通らない専用のプライベート接続。高信頼・一貫した低遅延・広帯域。
- ExpressRoute Direct
- 接続事業者を介さず、10 Gbps または 100 Gbps の専用ポートペアを Microsoft のエッジルーターへ直接占有して接続する ExpressRoute の形態。1 つの物理接続上に複数の ExpressRoute 回線(サブレット化)を作成でき、大容量・低レイテンシが必要な用途向け。
- ExpressRoute FastPath
- 通常は ExpressRoute ゲートウェイを経由するデータパスを、対応 SKU で仮想ネットワークゲートウェイを迂回させて低遅延・高スループットにするオプション。一部の構成(UDR やロードバランサー経由)では適用対象外になる制約がある。
- ExpressRoute ゲートウェイ
- ExpressRoute 回線と VNet を接続する仮想ネットワークゲートウェイ。SKU で帯域とパフォーマンスが決まる。
- ExpressRoute ピアリング(プライベート/Microsoft)
- ExpressRoute の経路種別。プライベートピアリング=VNet への到達、Microsoft ピアリング=Microsoft 365/PaaS の公開サービスへ専用線で到達。常に BGP で交換する。
- ExpressRoute 上の暗号化
- プライベート回線である ExpressRoute の通信を暗号化する手段。MACsec で接続自体を、または IPsec VPN を ExpressRoute 上に重ねて保護する。
- External access(フェデレーション)
- 外部ドメインのユーザーと Teams でチャットや通話をできるようにする仕組み。相手は自社のチームのメンバーにはならない。ゲストをメンバーにする guest access とは別。
- External Attack Surface Management(EASM)
- 組織が把握していない、インターネットに公開された資産を外側から発見し、外部攻撃面を可視化する。自分の資産の既知脆弱性を内部評価する Defender 脆弱性管理とは役割が異なる。
- Fabric のセキュリティとガバナンス(ワークスペースロール・機密ラベル・デプロイパイプライン)
- ワークスペースロール=Admin > Member > Contributor > Viewer の階層(最小権限)。データ単位はアイテム権限・行レベルセキュリティ(RLS)・列レベル/オブジェクト権限で細かく制御。ガバナンス=機密ラベル(Microsoft Purview Information Protection でデータ分類・暗号化/透かし)と Purview(監査・系列リネージ・データカタログ)。リリース=デプロイパイプライン(開発→テスト→本番で成果物を昇格・差分比較)と Git 統合(CI/CD)。テナント全体の機能可否は管理ポータルのテナント設定で統制。
- Fabric の監視と最適化(監視ハブ・容量メトリック・V-Order・OPTIMIZE)
- 監視=監視ハブ(パイプライン/ノートブック/Spark の実行履歴・状態・所要時間)/容量メトリックアプリ(容量ユニット CU の消費・スロットリングを可視化し過負荷源を特定)/Data Activator(データ条件で通知/アクションを自動起動)。エラー対応=再試行ポリシー(一時障害)+失敗パス。最適化=V-Order(読み取り最適化された並び)/OPTIMIZE(小さなファイルの圧縮統合・small files 問題の定番対処、Z-Order でデータスキッピング)/VACUUM(古い未参照ファイル削除)/パーティション設計/Spark・容量のチューニング。
- Fabric の取り込みと変換(パイプライン・Dataflow Gen2・Spark・メダリオン)
- 取り込み=データパイプライン(Copy/ノートブック等のアクティビティをオーケストレーション・スケジュール・再試行)/Copy アクティビティ(大量データ高速搬送・増分はウォーターマーク)/データフロー Gen2(Power Query でノーコード整形)/ショートカット(参照)/Eventstream(ストリーミング)。変換=Spark ノートブック(PySpark/Spark SQL・大規模/ML)/T-SQL(Warehouse・セットベース)/Dataflow Gen2(ノーコード)。設計はメダリオン=ブロンズ(生)→シルバー(クレンジング/結合)→ゴールド(集計/ビジネス向け)で段階化し各層を Delta で保存。
- Face(顔)
- 画像内の顔の検出・属性分析に特化(責任あるAIの観点で一部機能は制限)。
- fail-fast
- matrix 戦略の設定。true(既定)で 1 つ失敗すると残りを打ち切り、false で全組み合わせを最後まで実行する。原因切り分けには false。
- FHRP(First Hop Redundancy Protocol)
- 複数の物理ルータを1台の仮想ルータとして見せ、端末のデフォルトゲートウェイ(最初のホップ)を冗長化する一群のプロトコルの総称。標準規格のVRRPやCisco独自のHSRP・GLBPが代表例で、いずれも仮想IPアドレスを介して端末設定を変えずにゲートウェイ障害からの自動復旧を実現する。
- FHS(ファイルシステム階層標準)
- 標準的なディレクトリ構成を定める規約。/etc 設定・/var 増減データ(ログ等)・/home ユーザー・/usr アプリ・/bin,/sbin 基本コマンド・/opt 追加ソフト・/tmp 一時・/boot カーネル・/dev デバイス・/proc,/sys 仮想FS。ディストリを越えてほぼ共通。
- FIFO(順序保証/重複排除)
- SQS/SNS の FIFO 種別。メッセージグループ単位で厳密な順序を保証し、重複排除 ID(または内容ベース重複排除)で5分間の重複送信を排除する。標準より低スループットだが、順序と「ちょうど一度」が要る処理向け。
- Filestore
- フルマネージドな NFS ファイルストレージ。Compute Engine VM や GKE から共有ファイルシステムとしてマウントし、低レイテンシの共有ストレージを提供する。
- FILLFACTOR
- テーブルやインデックスのページに意図的に空き領域を残す割合を指定するストレージパラメータ(既定100=空きなし)。UPDATE の多いテーブルで下げておくと HOT(Heap-Only Tuple)更新が起きやすくなり、インデックス更新のオーバーヘッドを減らせる。
- FILTER / ALL 関数
- フィルターを操作する DAX 関数。FILTER=条件でテーブルを絞る、ALL=フィルターを解除(合計や構成比の分母に使う)。
- Filter 関数(Power Fx)
- 条件に一致するレコードだけを抽出する関数。ギャラリーや一覧の絞り込みに使う。委任に対応する書き方が重要。
- find
- 指定パス以下を実時間で走査し、条件に合うファイルを探すコマンド。-name(名前)・-type(f/d)・-size・-mtime(更新日。-7 は7日以内)・-user で絞り、-exec コマンド {} \; で見つけたファイルへ一括操作する。
- fine-grained PAT(細粒度)
- 権限・対象リポ・有効期限を細かく絞れる Personal Access Token。最小権限+有効期限で発行し、漏洩時は失効。組織ポリシーで承認制/制限できる。
- Firestore
- モバイル/Web アプリのデータ向けのスケーラブルなドキュメント型 NoSQL データベース。
- Flexible NetFlow
- 収集するキー・非キーフィールドを自由に組み合わせて定義できるフローレコード(record)、宛先を指定するエクスポータ(exporter)、両者を結び付けるモニタ(monitor)の3要素を定義し、モニタをインタフェースへ適用することでフロー統計の収集項目を柔軟にカスタマイズできるNetFlowの実装。従来の固定フィールドのNetFlowに比べ、必要な情報だけを効率よく収集できる。
- FM 選定(基盤モデルの選択)
- 用途に最適な基盤モデルを選ぶ作業。ベンチマーク・能力と制約(モダリティ・コンテキスト長・言語)・コスト・レイテンシ・ライセンスを評価し、必要なら小規模パイロットで比較する。最大モデルが常に最適とは限らず、タスク適合で選ぶ。
- FMEA(故障モード影響解析)
- 構成部品ごとに想定される故障モード(壊れ方)を洗い出し、それがシステム全体に与える影響を評価するボトムアップ型の解析手法。個々の部品の故障からシステムレベルの影響を積み上げて分析するため、設計段階で見落としがちな単一故障の影響を体系的に洗い出せる。機能安全の設計プロセスで必須の解析として位置づけられる。
- Follow
- 開発者の公開活動を自分のフィードで追う操作。
- fork(フォーク)
- GitHub 上で、リポジトリを自分のアカウントへ複製する操作。OSS 貢献の起点。
- Foundry Agent Service(基礎)
- Microsoft Foundry でエージェントを構築・実行するマネージドサービス。モデル・指示(システムプロンプト)・ツール(ナレッジ・関数)・スレッドを組み合わせて目的志向の AI を作る。
- Foundry の評価と安全性
- 生成 AI の品質を、グラウンド性・関連性・流暢さなどの指標と手動評価で測り、コンテンツフィルターやリスク評価で安全性を担保してからデプロイする。
- frontline teams
- 現場(フロントライン)従業員向けに、シフトや定型業務に適したチーム体験を提供する構成。
- FSLogix
- ユーザープロファイルを VHD/VHDX コンテナとして共有ストレージに置き、ログイン時にマウントする仕組み。プール型のように毎回別の VM にログインしても設定/データを保てる。Profile Container・ODFC・Cloud Cache・アプリケーションマスキングを含む。
- FSLogix Cloud Cache
- プロファイルコンテナを複数のストレージプロバイダー(複数リージョン/アカウント)へ冗長化し、片方が落ちても継続できる高可用性を提供する FSLogix の機能。バックアップ(時点復元)の代替ではない。
- FSLogix Profile Container
- ユーザープロファイル全体を 1 つのコンテナとして持ち運ぶ FSLogix の基本機能。Office/Outlook データだけを分離する ODFC(Office Container)と使い分ける。
- FTA(故障の木解析)
- システムに発生してほしくない望ましくない事象(トップ事象)を頂点に置き、それを引き起こしうる要因を論理ゲート(AND/OR)でツリー状に分解していくトップダウン型の解析手法。FMEAとは逆方向のアプローチで、複数の故障が重なって初めて重大事故に至るような組合せ的なリスクを可視化するのに向く。
- FTP・SFTP・TFTP(ファイル転送プロトコル)
- ファイル転送用プロトコル群。FTP(ポート20/21)は平文で認証・データを送るため盗聴に弱く、SFTPはSSH(ポート22)上で暗号化して転送する安全な方式、TFTP(ポート69・UDP)は認証なしの軽量な転送でルータ等の設定ファイル転送に使われる。
- Function Calling(関数呼び出し)
- LLMに外部ツールやAPIを使わせる基本的な仕組み。呼び出し可能な関数のスキーマ(名前・引数・説明)をモデルに渡すと、モデルは実行はせず「この関数をこの引数で呼びたい」という構造化された提案(JSON等)だけを返し、実際の実行と結果の返送はアプリ側が担う。
- Functions のトリガー
- 関数を起動するきっかけ。HTTP(要求)、タイマー(定時)、Blob/Queue/Event(データ操作)、Webhook などがある。1 関数に 1 トリガー。
- Functions のホスティングプラン
- 実行環境の課金/性能の選択。Flex Consumption(現行主流・高速スケール・VNet・常時準備インスタンス可)/従量課金(旧 Consumption・自動スケール・コールドスタート有)/Premium(事前ウォーム・VNet)/専用(App Service プラン)。
- Gateway Load Balancer
- サードパーティ NVA(ファイアウォール/IDS)を透過的に挿入するための専用ロードバランサー。トラフィックを検査用 NVA に振り向ける。
- Gateway Load Balancer(GWLB)
- サードパーティの仮想アプライアンス(次世代ファイアウォール・IDS/IPS)をトラフィック経路に透過的に挿入するための L3 ゲートウェイ。GENEVE(ポート 6081)でパケットをカプセル化してアプライアンス群へ送り、GWLB エンドポイント(GWLBe)をルートテーブルに挟むことで、送信元 VPC のトラフィックを検査 VPC へ回す。
- gcloud CLI
- Google Cloud をコマンドラインから操作する公式 CLI。リソースの作成・構成・自動化やスクリプト化を担い、Cloud Shell にもプリインストールされる。
- Gemini
- Google Cloud の中核となる生成 AI モデル。文章生成・要約・コード支援・画像理解などを担い、各サービスや Workspace に組み込まれる。
- Gemini Cloud Assist
- Google Cloud コンソール内で、ログ・メトリクス・トレースやリソース構成を分析し、トラブルシューティングやアーキテクチャ設計の提案を自然言語で行う AI アシスタント。運用担当者がコンソールを横断して原因調査する時間を短縮する目的で使う。
- Gemini Code Assist
- IDE 上でコード補完・生成・説明・レビューを支援する AI ペアプログラミング機能。個人向け無償枠と、社内コードベースを踏まえた補完やエンタープライズ管理が可能な Enterprise 版がある。VS Code や JetBrains 系 IDE の拡張として使う。
- Gemini for Google Cloud
- コード補完・説明やクラウド運用のトラブルシュート助言など、開発・運用を支援する Gemini。
- Gemini for Google Workspace
- Docs・Gmail・Sheets・Slides・Meet などに Gemini を組み込み、文書作成・メール・要約・会議メモを支援する生産性ソリューション。
- Gemma
- Google の軽量なオープンモデル群。Gemini と同じ研究・技術から派生し、オンデバイスや自前ホスティングでの利用・ファインチューニングに向く。
- GenAI ゲートウェイ
- FM 利用を集約する中央抽象レイヤー。認証・レート制限・コスト配賦・オブザーバビリティ・ポリシーを一元化し、企業での安全で統制された GenAI 利用を実現する。
- GenAIOps
- MLOps の考え方を生成 AI(Azure AI Foundry・基盤モデル・プロンプト)へ拡張した運用プラクティス。プロンプトやエージェントのフロー、評価指標(グラウンディング・有害性等)をコードやコンフィグとして Git 管理し、CI/CD で評価→デプロイ→監視→改善のサイクルを自動化する。
- General Purpose レベル
- Azure SQL のバランス型サービスレベル。計算とリモートストレージを分離し、コストと性能のバランスが良い汎用ワークロード向け。
- geo 復元
- GRS の geo 冗長バックアップから別リージョンへ復元する DR 手段。非同期コピーのため RPO は大きめになる。
- gh CLI
- 端末から Issue・PR・リポジトリを操作できる公式コマンドラインツール(内部で API を使う)。
- Gist
- 単一ファイルやコード断片を手軽に共有できる軽量リポジトリ。
- Git
- もっとも普及している分散型バージョン管理ツール。各自が全履歴のコピーを手元に持つ。
- Git 統合(Fabric)
- ワークスペースを Azure DevOps/GitHub のリポジトリに接続し、アイテムをソース管理する仕組み。バージョン管理と CI/CD の基盤になる。
- Git 統合(ソース管理)
- コンピューティングインスタンスを Git リポジトリと連携させ、ノートブックやスクリプトをバージョン管理・協働する仕組み。
- GitHub
- Git リポジトリをクラウドでホスティングし、Pull Request・Issue・レビュー・Actions などの協業機能を加えるサービス。
- GitHub Actions
- CI/CD などを自動化するワークフロー基盤。.github/workflows に YAML で定義し、ランナー上で実行。
- GitHub Advanced Security(GHAS)
- コード・シークレット・依存関係を SDLC 全体で保護する機能群。2024年後半に Code Security(CodeQL/コードスキャン)と Secret Protection(シークレットスキャン/プッシュ保護)の2つの独立製品へ再編・個別課金化された。Dependabot 等の依存関係/サプライチェーン機能は無料で提供。公開リポは多くが無料、プライベート/Enterprise は製品ライセンスが必要。
- GitHub App
- GitHub 上で動く自動化・連携の第一級の主体。リポジトリ単位でインストールでき、必要な権限だけを細かく(fine-grained)付与する最小権限モデルのため、自動化やIntegration開発では OAuth App より推奨される。ユーザーではなくインストール(installation)としてAPIを呼び出し、専用のBotアカウントを持つ。
- GitHub Codespaces
- ブラウザやエディタからすぐ使えるクラウド上の開発環境。devcontainer.json で環境をコード化。
- GitHub Connect
- GitHub Enterprise Server/Cloud と GitHub.com を連携し、ライセンス同期・統合検索・サーバーからの Actions 利用などを有効にする機能。
- GitHub Copilot
- IDE・CLI・GitHub.com で使える AI コーディング支援。提案は人がレビューして責任を持って採否する。
- GitHub Copilot CLI
- ターミナルから Copilot を使う仕組み。コマンドの提案・説明、シェルスクリプト生成、ファイル操作を自然言語で行う。IDE 拡張とは別にインストール・認証する。
- GitHub Desktop
- コミット・ブランチ・Pull Request を GUI で扱えるデスクトップアプリ。コマンドに不慣れでも Git 操作ができる。
- GitHub Discussions
- 質問・アイデア共有などの会話に適した場。作業の追跡は Issues を使う。
- GitHub Docs
- 機能の使い方を網羅した公式ドキュメント。まず検索すべき一次情報。
- GitHub Enterprise
- 複数の Organization を束ねて一元管理する大規模組織向けの形態。Cloud(GitHubホスト)と Server(自社運用)がある。
- GitHub Enterprise Cloud(GHEC)
- GitHub がホストするクラウド版の Enterprise プラン。インフラ運用は GitHub 側が担い、新機能やセキュリティ更新はセルフホスト版(GHES)より先行して利用できることが多い。データレジデンシー機能を使うと保存先リージョンを選べる。
- GitHub Enterprise Server(GHES)
- 自社のデータセンターやプライベートクラウドに構築するセルフホスト版 Enterprise。データを自社管理下に置けるためコンプライアンス要件に応えやすい一方、機能は定期リリース(feature release)に追従して提供され、一部のクラウド専用機能(例:一部のセキュリティ機能)は遅延したり提供されなかったりする。管理者自身がアップグレードやバックアップを運用する。
- GitHub Flow
- ブランチ作成→コミット→PR→レビュー→マージ→デプロイの軽量なブランチ運用。main は常にデプロイ可能に保つ。
- GitHub Marketplace
- GitHub と連携するアプリや Actions のワークフローを見つけて導入できるマーケットプレイス。CI/CD やコード品質などの機能を拡張する。
- GitHub Mobile
- スマートフォンから通知の確認・Issue/PR の操作・レビューができる公式アプリ。Copilot Chat にもモバイルから利用できる。
- GitHub Packages
- npm・Maven・NuGet・RubyGems・コンテナ(GitHub Container Registry / GHCR)などのパッケージをリポジトリ近傍でホスティングする機能。権限は GitHub の認可と統合し、Actions から発行/取得できる。
- GitHub Pages
- リポジトリの内容から静的サイトを無料でホスティングする機能(動的処理は不可)。
- GitHub Projects
- Issue や Pull Request を横断して計画・追跡する柔軟なプロジェクト管理ツール(Projects v2)。ボード/テーブル/ロードマップのビュー、カスタムフィールド、組み込みの自動化を備える。
- GitHub Security Advisory(GHSA)
- GitHub Advisory Database に収録される脆弱性情報。Dependabot の検知の裏付け。リポジトリのセキュリティアドバイザリを使うと、自プロジェクトの脆弱性を非公開で修正してから公開できる。
- GitHub Skills
- 実際の操作を通して学べる公式のハンズオン教材。
- GitHub Sponsors
- OSS の開発者やプロジェクトを金銭的に支援する仕組み。Star(無償のお気に入り)とは別。
- GitHub Support
- 管理者の設定・権限では解決できない障害・不具合・GHES のシステム障害などを扱う窓口。問題はまず「管理者で解決できるもの」と「Support 案件」に切り分ける。
- github コンテキスト
- イベントやリポジトリの情報を持つコンテキスト。github.ref(ブランチ/タグ参照)や github.event(イベントペイロード)などを参照できる。
- GitHub ホスト型ランナー
- GitHub が用意・更新・破棄する使い捨ての仮想環境。ジョブごとにクリーンで、一般的な CI に向く。利用分課金(無料枠あり)。
- GITHUB_TOKEN
- 各ワークフロー実行に自動発行される一時的・スコープ付きの資格情報。permissions キーで最小権限(例 contents: read)に絞り、書き込みが要るジョブだけ昇格する。長期の PAT は避ける。
- github.dev
- リポジトリで「.」キーを押すと開くブラウザ内の軽量エディタ。実行環境は持たない。
- GitOps
- Git リポジトリを唯一の信頼できる情報源(SSOT)とし、宣言的な望ましい状態へ継続的に同期(リコンサイル)する運用手法。手作業の変更によるドリフトを防ぐ。
- GKE Autopilot
- GKE のクラスタ運用モードの一つで、ノードのプロビジョニング・スケーリング・アップグレード・セキュリティ強化まで Google がフルマネージドで行う。Pod 単位の課金で、ノードプールの構成や SSH アクセスは持てない代わりに運用負荷が最小になる。
- GKE Enterprise(Anthos)
- オンプレミスや複数のクラウドにまたがって一貫した方法でコンテナを運用・管理できるプラットフォーム。ハイブリッド/マルチクラウドを実現する。
- GKE Standard
- GKE のクラスタ運用モードの一つで、ノードプールのマシンタイプ・スケーリング設定・ノードへの SSH アクセスまで自分で構成できる。Autopilot より柔軟だが、ノードの容量管理やセキュリティパッチ適用の一部は利用者側の責任になる。
- Glacier 取り出し階層
- S3 Glacier 系からの復元速度の選択肢。Glacier Instant Retrieval=即時。Flexible Retrieval=迅速(1〜5分)/標準(3〜5時間)/大容量(5〜12時間)。Deep Archive=標準12時間/大容量48時間。速度とコストのトレードオフで選ぶ。
- Glue Data Quality(DQDL)
- データカタログやパイプライン上のデータ品質を、DQDL(ルール定義言語)で表現したルールに照らして検証・スコアリングする機能。
- Glue クローラ
- データソースをスキャンしてスキーマとパーティションを推論し、Glue データカタログにテーブル定義を自動登録/更新するコンポーネント。
- Glue データカタログ
- テーブル・スキーマ・パーティションの中央メタデータストア。Athena・Redshift Spectrum・EMR が共通のメタデータとして参照する。
- Gmail のルーティング
- 特定条件に一致するメールを別の宛先やサーバーへ転送・振り分ける Gmail の設定。コンプライアンス目的のコンテンツ/添付制限と併用する。
- Gmail(管理)
- Workspace のメールサービス。管理者はルーティング/受信ルール、コンテンツ・添付ファイルの制限、配信状況の確認、メールヘッダー分析(なりすまし調査)などを設定・運用する。
- GnuPG(gpg)
- ファイルの暗号化・復号・署名を行う公開鍵ツール。暗号化は受取人の公開鍵で行い(gpg -e -r 受取人)、受取人だけが秘密鍵で復号できる。署名は自分の秘密鍵で行う。鍵束は ~/.gnupg/、パスフレーズ管理は gpg-agent。
- Google Chat
- Google Workspace のチームメッセージング。ダイレクトメッセージとスペース(旧ルーム)でのコラボを提供し、管理者は履歴・外部参加・モデレーションを制御する。
- Google Cloud Armor
- 外部 Application LB の前段で適用するエッジ/バックエンドのセキュリティポリシー。WAF(SQLi/XSS/RFI)、高度な DDoS 防御と機械学習の Adaptive Protection、レート制限、bot 管理、Threat Intelligence を提供する。
- Google Drive(共有設定)
- Workspace のファイルストレージ。管理者は共有範囲(社内/外部・リンク共有)、共有を許可/制限、共有ドライブの利用などを OU やグループ単位で制御する。
- Google Kubernetes Engine(GKE)
- マネージド Kubernetes。多数のコンテナを自動配置・スケール・自己修復しながら大規模に運用できる。
- Google SecOps Risk Analytics
- 検出にリスクスコアを割り当て、資産/ユーザーの異常行動を発見してリスクプロファイルに合う脅威を優先する仕組み。エンティティリスクスコアの急上昇から異常を見つける。
- Google SecOps(SIEM/SOAR)
- 旧 Chronicle。大量のセキュリティログを取り込み、検出ルールで脅威を見つけて調査する SIEM と、対応をプレイブックで自動化/オーケストレーションする SOAR を備えたセキュリティ運用プラットフォーム。Security Command Center と統合して使う。
- Google Threat Intelligence(GTI)と IOC
- 既知の悪性 IP/ドメイン/ハッシュ(IOC=侵害指標)や攻撃者の戦術/技術(TTP)を提供する脅威インテリジェンス。検出やハンティング、フォレンジック分析でアーティファクトの悪性判定に使う。
- Google Vault(保持ルールとホールド)
- データを一定期間保持し期限後に削除する保持ルールと、訴訟/調査のためにデータを保全するホールドを担う。ホールドは保持ルールの削除に優先する。保全済みデータは eDiscovery で検索・エクスポートする。
- Google Zero Touch Enrollment
- 対応する Android デバイスを、リセラー経由で Google のポータルに登録しておくことで、初回起動時に自動的に任意の EMM(Intune 等の DPC)の管理プロファイルを適用する仕組み。Google が提供する汎用の登録方式であり特定の EMM に限定されず、ユーザー操作なしで fully managed 構成まで到達できるため、法人一括調達の展開に向く。
- GPIO(汎用入出力ポート)
- ソフトウェアからレジスタ設定により入力・出力・プルアップ/プルダウン等を切替可能な汎用のデジタル入出力ピン。特定の専用機能を持たず用途を自由に割り当てられるため、スイッチ入力・LED制御・簡易な外部デバイス制御など組込みシステムの最も基本的なI/O手段として使われる。
- GRANT/REVOKE
- ロールに対してテーブルなどオブジェクトへの権限を付与・剥奪する DCL 文。GRANT SELECT のように特定権限のみ、GRANT ALL のように全権限をまとめて付与できる。
- GRE(Generic Routing Encapsulation)
- 元のパケット全体を別のIPヘッダで包んでトンネリングするカプセル化専用のプロトコル。マルチキャストや他のプロトコルなど、通常インターネット越しに直接運べないトラフィックもトンネル内に通せるが、GRE自体は暗号化を行わない。機密性が必要な場合はIPsecと組み合わせる(GRE over IPsec)。
- Ground Truth と作る/使うの判断
- SageMaker Ground Truth は学習データのラベリングを行い、ワークフォース(Mechanical Turk=公開・安価だが機密不可/ベンダー管理/プライベート=社内・機密向け)と自動ラベリング(アクティブラーニングで人手を曖昧な例だけに絞りコスト削減)、アノテーション統合(多数決)で品質を担保する。構築方針は AI サービス(一般課題・学習不要・最速)→各サービスの Custom→SageMaker フルカスタム(固有要件)の連続スペクトラムで選ぶ。
- Grounding with Google Search
- モデルの回答を Google 検索に基づかせ、最新の一般情報を反映してハルシネーションを減らすグラウンディング手段。
- gRPC
- HTTP/2 上で動く低遅延・型付き(Protocol Buffers)の RPC フレームワーク。内部のサービス間通信に向く。公開 Web には REST も選ぶ。
- GuardDuty の検出と Security Hub
- GuardDuty は VPC フローログ・DNS ログ・CloudTrail を機械学習/脅威インテリジェンスで分析し脅威を検出。Security Hub は複数のセキュリティサービスの検出を集約し、標準(CIS/PCI 等)への準拠を評価する。
- GuardDuty 検出器 / 脅威リスト
- 検出器=リージョンごとに GuardDuty を有効化する単位。CloudTrail・VPC フローログ・DNS ログを機械学習と脅威インテリジェンスで分析する。信頼された IP リスト(誤検知抑制)と脅威 IP リスト(独自ブロック対象)をカスタムで追加できる。
- GUI/CUI
- GUI はグラフィカルなデスクトップ操作、CUI(CLI)は文字ベースのコマンド操作。サーバーは軽量な CUI が基本で、GUI はデスクトップ用途に限る。
- HA VPN
- 冗長化された 2 本のトンネル(それぞれ別の外部 IP)を使い 99.99% の可用性 SLA を提供する、Google 推奨の IPSec VPN。オンプレミスや他クラウド・他 VPC との接続に使い、BGP による動的ルーティングを前提とする。新規構築では基本的にこちらを選ぶ。
- HANA System Replication(HSR)
- SAP HANA がプライマリ→セカンダリへ DB ネイティブに同期/非同期で複製する仕組み。HA(同一/近接リージョン)にも DR(別リージョン)にも使う。HANA の DR は Azure Site Recovery でなく HSR を推奨する。
- HA構成(高可用性構成)
- サーバーやサービスの停止時間を最小化するための構成。冗長化・クラスタ・ロードバランシングなどを組み合わせ、単一障害点(SPoF)を排除して稼働率を高める。
- HDD/SSD
- 大容量記憶装置。HDD は磁気ディスクで安価・大容量だが可動部があり遅い。SSD はフラッシュメモリで高速・耐衝撃だが書き込み回数に上限がある。ほかに配布・保存用の光学ストレージ(DVD 等)。
- HEAD
- 現在チェックアウトしているブランチ/コミット、つまり今の作業位置を指す参照。
- Hello/Deadタイマー(OSPF)
- OSPFが隣接ルータの生存を確認する周期を定める2つのタイマー。Helloタイマーの間隔でHelloパケットを送り合い、Deadタイマー(既定でHelloの4倍)の間Helloが届かなければ隣接ルータをダウンとみなし経路を再計算する。隣接するインタフェース間でHello/Deadタイマーの値が一致していないと隣接関係が形成されない。
- HIDS(ホストベース侵入検知)とアンチマルウェア
- HIDS(ホストベース侵入検知システム)は個々のホスト上でファイル改ざん・プロセス・ログ等を監視し侵入の兆候を検知するソフトウェア。アンチマルウェア(AV)はシグネチャや振る舞いをもとに既知・未知のマルウェアを検出・隔離・除去するソフトウェアで、いずれもネットワーク境界ではなく端末側で動作する対策。
- HMAC(鍵付きハッシュメッセージ認証コード)
- 共有した秘密鍵とハッシュ関数を組み合わせてメッセージ認証コード(MAC)を生成する方式。受信側は同じ鍵で再計算して照合し、改ざんの有無と「鍵を持つ相手からの送信であること」を検証できる。公開鍵基盤を要さず完全性・真正性を確保できる。
- HOLブロッキング
- 先頭(Head of Line)のパケットやリクエストが何らかの理由(受信側バッファ枯渇、順序保証の待ち等)で処理を待たされ、後続の本来処理可能なパケット・リクエストまで足止めされてしまう現象。単一FIFOキューを共有する構成やTCPのパケットロス時の順序復元待ち、HTTP/1.1のパイプライン処理などで発生し、仮想出力キュー(VOQ)の採用やHTTP/2以降の多重化により緩和される。
- Hotpatch
- 対応する Windows(Enterprise E3/E5 等の要件あり)に対し、セキュリティ更新プログラムを再起動せずに適用できる更新方式。従来の月例更新に比べ再起動によるダウンタイムと生産性ロスを削減でき、月例のベースライン更新は定期的な再起動を伴う周期と組み合わせて運用する。
- HSM(ハードウェアセキュリティモジュール)
- 暗号鍵の生成・保管・演算を専用のハードウェア内で行い、ソフトウェアや外部から秘密鍵を取り出せないように保護する耐タンパ性を備えた装置。秘密鍵をOSやアプリケーションのメモリ上に平文で置かないため、マルウェア感染やサーバー侵害が起きても鍵の漏えいリスクを大きく下げられる。鍵管理ライフサイクルにおける「保管」段階の代表的な実装手段として用いられる。
- HSRP(Hot Standby Router Protocol)
- FHRPを実現するCisco独自プロトコル。グループ内で最も優先度(priority)が高いルータがアクティブルータとなって仮想IP/仮想MACアドレスを担当し、次点はスタンバイルータとして待機する。アクティブルータが復旧した際に自動的に主導権を取り戻すかどうかはプリエンプトの設定で決まる。
- HTTP
- Webブラウザとサーバー間でページやデータをやり取りする、暗号化されないアプリケーション層プロトコル(ポート80)。通信内容は平文で盗聴・改ざんの恐れがあるため、現在はTLSで保護されたHTTPSの利用が標準になっている。
- HTTP コネクタ
- 任意の Web API を直接呼び出す汎用コネクタ。専用コネクタがないサービスと REST で連携できる。プレミアム。
- HTTP/3(QUIC)
- TCPではなくUDPベースのQUICをトランスポートに用いるHTTP。QUIC内の各ストリームが独立して再送・順序制御を行うため、TCP上のHTTP/2で問題になったトランスポート層のHoL(Head-of-Line)ブロッキング(1ストリームの損失が全ストリームを足止め)を回避でき、パケットロス率の高い回線で有利。
- HTTPS
- HTTPをTLSの上に載せて運ぶプロトコル。通常のHTTPと違い通信内容が暗号化され、途中経路での盗聴・改ざんを防げる。ブラウザは証明書を検証してサーバーの正当性を確認し、Webサイトの標準的な通信方式になっている。
- HTTPメソッドとHTTPステータスコード
- HTTPメソッドはリクエストの意図を表す(GET=取得・POST=作成・PUT=全体置換・PATCH=部分更新・DELETE=削除)。HTTPステータスコードは応答の結果を表す(2xx=成功・3xxリダイレクト・401=未認証・403=権限不足・404=不在・429=レート超過・5xx=サーバエラー)。API呼び出しのトラブルシューティングは、送ったメソッドと返ってきたステータスコードの組み合わせから原因を切り分ける。
- human-in-the-loop(人の介在)
- 重要な意思決定で AI の出力をそのまま使わず、人が最終確認・承認する仕組み。影響の大きい用途で必須。
- Hyperscale レベルとページサーバー
- 最大 100TB 級まで拡張できる Azure SQL のサービスレベル。ページサーバーでストレージを分離し、スナップショットベースの高速バックアップ/復元と迅速なスケールを実現する。
- Hブリッジ回路
- 4個のスイッチング素子をH字状に配置し、モータなど負荷への電流の向きを切り替えることで正転・逆転・ブレーキ・フリーの各状態を制御できる駆動回路。MCUのデジタル出力だけでは駆動できない大電流のモータをPWM信号と組み合わせて制御する際に用いられる、モータドライバの基本構成。
- I2C(Inter-Integrated Circuit)
- SDA(データ)とSCL(クロック)の2本の信号線で複数のデバイスを接続できるシリアル通信規格。各デバイスにアドレスを割り当てることで1つのバスに多数のセンサ/ICを接続でき配線数を抑えられるが、通信速度はSPIより低速で、複数マスタ対応時は調停(アービトレーション)機構を持つ。低速・多デバイス接続の要件に向く。
- IaaS(Infrastructure as a Service)
- 仮想マシンなどのインフラを借りるモデル。OSから上は利用者が管理し、最も自由度が高い(例:Azure Virtual Machines)。
- IaC ツール(Terraform / Helm)
- Bicep/ARM に加え、マルチクラウドの Terraform(宣言的・状態管理)や、Kubernetes 配布の Helm チャートをパイプラインから適用してインフラとアプリ構成をコード化する。
- IAM Access Analyzer
- 外部に公開された S3/ロール/KMS/Secrets 等を検出する外部アクセス分析、未使用のロール/権限/アクセスキーを洗い出す未使用アクセス分析、ポリシーの検証、CloudTrail からの最小権限ポリシー生成を行い、最小権限を支援するサービス。
- IAM Identity Center(旧 AWS SSO)
- 複数の AWS アカウントとアプリケーションへのアクセスを一元管理するサービス。外部 IdP と連携し、許可セットを使ってアカウント横断のアクセスを集中付与する。
- IAM インラインポリシー
- 単一のIAMユーザー・グループ・ロールに直接埋め込まれ、その対象と1対1で厳密に紐づくポリシー。他のIDにアタッチして再利用することはできず、対象を削除すればポリシーも一緒に消える。特定の1つのIDだけに例外的な権限を持たせたい限定的な用途で使う。
- IAM グループ
- 複数の IAM ユーザーをまとめてポリシーを一括付与するための入れ物。グループ自体はプリンシパルではなくロールを引き受けることもできない(あくまでユーザーへの権限配布を簡略化する仕組み)。グループの入れ子(グループの中にグループ)は不可。
- IAM ポリシーシミュレーター
- 実際にリクエストを行わずに、特定のプリンシパルがあるアクションを許可されるかをポリシー評価で検証するツール。デプロイ前の権限テストに使う。
- IAM ポリシーの構造(Effect/Action/Resource/Condition)
- JSON ポリシーの構成要素。Effect=Allow/Deny、Action=許可する API(s3:GetObject 等)、Resource=対象 ARN、Condition=条件(IP・MFA・タグ等)、Principal=誰に(リソースポリシーのみ)。最小特権はこれらを具体化して絞る。
- IAM ポリシー評価ロジック
- アクセス可否の判定順序。明示的 Deny があれば常に拒否(最優先)、なければ明示的 Allow があるか確認し、Allow があり Deny がなければ許可、どこにも Allow がなければ暗黙的拒否。優先順位は「明示的拒否 > 許可 > 暗黙的拒否」。
- IAM ユーザー
- 人やアプリケーションに対応する長期的な ID で、パスワードやアクセスキーなど長期認証情報を持てる。人にはロール+一時認証情報を優先し、IAM ユーザーと長期キーの発行は最小限にとどめるのがベストプラクティス。
- IAM 管理ポリシー
- 複数のIAMユーザー・グループ・ロールにアタッチして再利用できる独立したポリシーオブジェクト。AWSが作成・更新するAWS管理ポリシー(手早いが粒度が粗い)と、自分で作成しバージョン管理できるカスタマー管理ポリシー(推奨、最小特権を実現しやすい)に分かれる。
- IAM 拒否ポリシーと IAM 条件
- IAM 拒否ポリシーは許可より優先して操作を明示的に禁止する(強制的なガードレール)。IAM 条件は時間/送信元 IP/リソースなどの属性で許可を条件付ける。両者で最小権限を精緻化する。
- IAM 条件キー
- ポリシーの Condition で使うキー。aws:SourceIp(送信元 IP)、aws:MultiFactorAuthPresent(MFA 必須)、aws:PrincipalTag/ResourceTag(ABAC)、aws:SourceVpce(特定エンドポイント経由)等。きめ細かなアクセス制御の要。
- IAST(Interactive Application Security Testing)
- アプリケーションの実行中に内部の挙動(データフローや実際に到達したコード経路)を計測しながら脆弱性を検出する手法。ソースコードを静的に見るSASTと、外部から動かして検査するDASTの中間的な位置づけで、両者の長所を組み合わせる。
- ICMP
- データ転送ではなく制御・診断メッセージをやり取りするプロトコル。ping(到達確認)や traceroute(経路確認)、到達不能・TTL 超過の通知に使われ、ネットワーク疎通トラブルの切り分けに欠かせない。
- ID プロバイダー(IdP)
- Entra ID・Okta などの企業の認証基盤。SAML SSO で認証を担い、SCIM/チーム同期と組み合わせてアカウントとグループを一元管理する。
- Identity Secure Score
- Microsoft Entra ID の ID 態勢を数値で示す指標。現在のスコアと推奨改善策を提示し、MFA 強制や条件付きアクセス導入などで安全性を高める指針になる。
- Identity-Aware Proxy(IAP)
- ユーザーの ID に基づいてアプリやリソースへのアクセスを保護する仕組み。VPN なしで安全に公開でき、ゼロトラスト的なアクセス制御を実現する。
- IdFix
- オンプレ AD を Microsoft Entra ID に同期する前に、無効な UPN・重複プロキシ アドレス・不正文字などの書式エラー/重複を検出し修復する事前クレンジング ツール。
- IDS/IPSの検知方式(シグネチャ型/アノマリ型)
- シグネチャ型(不正検出型)は既知の攻撃パターン(シグネチャ)と一致する通信を検知する方式で、誤検知は少ないが未知の攻撃には対応できない。アノマリ型(異常検出型)は正常時の通信の統計的なふるまいから外れた通信を異常とみなす方式で、未知の攻撃も検知しうるが、正常な通信を誤って検知する(誤検知率が高くなる)傾向がある。
- IDSとIPS
- IDS(侵入検知システム)は不正な通信を検知して管理者に通知する仕組み、IPS(侵入防止システム)は検知に加えて通信を自動的に遮断する仕組み。ネットワーク境界や重要サーバーの防御に用いる。
- IEC 61508
- 電気・電子・プログラマブル電子(E/E/PE)安全関連系に関する機能安全の国際基本規格。産業機器全般に適用される汎用規格で、リスクの大きさに応じてSIL(安全度水準)1〜4を定義し、設計プロセス・検証・故障率の要求事項を規定する。自動車分野のISO26262など、業界別の派生規格の基礎になっている。
- IEEE802.1X(ポートベース認証)
- LANのポート単位でアクセス認証を行う規格。サプリカント(端末)が認証サーバ(RADIUS)に認証されるまで、スイッチのポートはEAPoLによる認証通信のみを許可し通常のデータ通信を遮断する。認証成功後にポートが開放される。EAP-TLSはクライアント証明書による強固な相互認証方式。
- If 関数(Power Fx)
- 条件が真かどうかで返す値を切り替える関数。表示/非表示、色分け、入力チェックなどの条件分岐に使う。
- if(条件分岐)とステータス関数
- ジョブ/ステップの実行可否を式で制御する。success()・failure()・cancelled()・always() のステータス関数で、失敗時のみ・常時などを表現する。
- IGMP(v2/v3)
- ホストがどのマルチキャストグループへの参加を希望しているかをルータへ通知するプロトコル。IGMPv2はグループ単位でのJoin/Leaveのみを扱うのに対し、IGMPv3はグループに加えて特定の送信元を指定するJoinができ、SSM(送信元指定マルチキャスト)を成立させるために必須となる。
- ignore_system_indexes / ignore_checksum_failure
- 破損クラスタの緊急起動用トラブルシューティングフラグ。ignore_system_indexes はシステムカタログのインデックスが壊れている場合にそれを無視してシーケンシャルスキャンで代替する。ignore_checksum_failure はデータチェックサム不一致を検出してもエラーで停止せず読み進める(データ破損を許容するリスクの高い設定)。
- IKE ポリシー
- IPsecトンネルの鍵交換方式を定めるInternet Key Exchangeの設定。暗号アルゴリズム・ハッシュ・Diffie-Hellmanグループ・SAの有効期間などをオンプレ機器とクラウド側VPNゲートウェイの両方で一致させる必要がある。
- Imagen
- Google の画像生成モデル。テキストの指示から新しい画像を生成する。
- IMAPとPOP3
- メール受信プロトコル。POP3はメールを端末にダウンロードしサーバから削除する設計で単一端末向け。IMAPはメールをサーバに残したまま各端末が状態(既読・フォルダ等)を共有でき複数端末利用に向く。いずれも認証情報保護のためTLSでの暗号化が推奨される。
- include / exclude(matrix)
- include は matrix に特定の組み合わせを追加(または値を付与)し、exclude は不要な組み合わせを除外する。
- Index Only Scan
- インデックスに含まれる列だけで結果を返し、ヒープ(実テーブル)へのアクセスを省く実行計画上のスキャン方式。クエリで参照する列がすべてインデックスに含まれる(カバリングインデックス)ときに選ばれ得るが、実際に効くかは Visibility Map の状態にも依存する。
- Inference Recommender
- 負荷テストを通じてモデルに最適なインスタンス種別・数・構成を推奨し、推論のコストと性能を最適化する機能。
- Information Barriers(情報バリア)
- Microsoft Purview の機能で、特定の部署やグループ間のチャット・通話・ファイル共有・チームの検索/参加を事前にポリシーでブロックする。証券のリサーチ部門と投資銀行部門の分離など、利益相反規制(コンプライアンス上の壁)を技術的に強制する場面で使う。事後に検知する Communication Compliance とは異なり、そもそも通信自体を成立させない事前予防の仕組み。
- information_schema
- SQL 標準に準拠した形式でデータベースのメタデータ(テーブル・列・制約など)を参照できるスキーマ。DBMS 実装に依存しない標準的な問い合わせが可能。
- Infrastructure as Code(IaC)
- インフラをコード(テンプレート)で宣言的に定義し、再現可能・バージョン管理可能にする考え方。手作業のドリフトを防ぎ、レビュー・自動化・複数環境の一貫構築を可能にする。AWS では CloudFormation・CDK が代表。
- Infrastructure Manager
- Terraform をマネージドで実行する Google Cloud のサービス。インフラをコード化(IaC)して再現可能にし、CI/CD と PR でレビュー・監査する。
- initdb
- 新しいデータベースクラスタを初期化するコマンド。データディレクトリを作成し、template1 と template0 を含む初期システムカタログを構築する。
- initdb --data-checksums
- クラスタ初期化時にデータページへチェックサムを付与するオプション。ストレージ破損によるデータ化けを検出しやすくなるが、有効/無効の切り替えには再初期化(または pg_checksums ツール)が必要。PostgreSQL 17 まではデフォルト無効で有効化には --data-checksums の明示指定が必要だったが、PostgreSQL 18 以降はデフォルトで有効化され、無効化するには --no-data-checksums を指定する。
- initramfs
- カーネルが本来のルートファイルシステムをマウントするために必要なドライバ類を含む初期 RAM ディスク。起動の橋渡しをする。
- inode
- ファイルの実体(サイズ・所有者・パーミッション・データ位置など)を管理するメタ情報。ファイル名は inode に付けたラベルにすぎない。ls -i で inode 番号を表示でき、番号が同じならハードリンク。
- inputs(ワークフロー入力)
- workflow_dispatch や workflow_call で受け取るパラメーター。type(string/boolean/choice/number/environment)・required・default・options を定義し、inputs.<名前> で参照する。
- instructions ファイル
- コーディング規約やレビュー基準を与え、Copilot に一貫した観点でレビュー/応答させる常時適用の設定ファイル。
- Intelligent Insights
- 性能問題を自動検出し、根本原因と改善案を診断ログとして出力する Azure SQL の機能。
- IntersightとWebex API
- IntersightはCiscoのコンピュート(UCS等)基盤をクラウドから一元管理・自動化するSaaSプラットフォームで、REST APIから状態取得や運用を自動化できる。Webex APIはWebexのメッセージ送信やミーティング作成等をプログラムから操作できるAPI群で、CUCMのAXL/UDSはオンプレの通話基盤を管理・検索するためのAPIインタフェース。
- Intune の Security Copilot agents
- Intune で AI を使って脅威を調査し、デバイス パフォーマンスを分析し、推奨をレビューして対応する。自分で書く決定的な PowerShell/Microsoft Graph 自動化に対し、AI 支援の調査・分析・推奨が役割(推奨はレビューしてから適用)。
- IoC(侵害の痕跡)とIoA(攻撃の兆候)
- IoC(Indicator of Compromise)は既に侵害が発生した事後の痕跡(不審なハッシュ値・通信先IP・ファイル名等)。IoA(Indicator of Attack)は攻撃がまだ進行中であることを示す兆候(異常なプロセス連鎖等)で、事後対応中心のIoCに対しIoAはリアルタイムの検知・阻止に使われる。
- IoT(モノのインターネット)
- センサーを搭載した家電・設備・車両など様々な「モノ」がインターネットに接続され、相互に情報をやり取りする仕組み。収集したデータの分析・活用が価値の源泉となる。
- IoTデバイスの省電力設計
- バッテリ駆動や環境発電で長期稼働するIoTデバイスに求められる設計方針。間欠動作(普段はスリープし必要時のみ起動)、低消費電力な無線方式(BLE・LPWA等)の選択、処理のエッジ側集約によるデータ送信量削減などが代表的手法。
- IoT脆弱性
- IoT機器に特有の脆弱性。初期パスワードのまま運用される、ファームウェア更新が提供されない・適用されない、限られた処理能力ゆえにセキュリティ機能が簡素、といった理由で侵害されやすく、ボットネットへの組み込みなどに悪用されることが多い。
- IP SLA
- 実際の業務トラフィックを流さず、合成(生成)したテストトラフィックを送出して到達性・遅延・ジッタ等の性能を能動的に測定する機能。測定結果をトラック(track)オブジェクトと連動させれば、経路の性能劣化や不通を検知して自動的にフローティングスタティックルート等へ切り替えるといった、能動的な障害対応に使える。
- IP アドレス(IPv4/IPv6)
- ネットワーク上のホストを識別する番号。IPv4 は32ビットをドット区切り4組(192.168.1.10)、IPv6 は128ビットをコロン区切り16進で表しアドレス枯渇を根本解決する。同一リンク内通信用の fe80:: リンクローカルアドレスが自動構成される。
- IP フォワード設定
- サーバーが自分宛てでないパケットを別のネットワークインタフェースへ中継(ルーティング)できるようにするカーネル設定。/proc/sys/net/ipv4/ip_forward の値や sysctl の net.ipv4.ip_forward で有効・無効を切り替え、Linux サーバーをルーターとして機能させる際に必要になる。
- IP マスカレード(GKE)
- GKE の Pod がクラスタ外へ送信する通信の送信元 IP を、ノードの IP に変換(SNAT)する仕組み。既定の非マスカレード対象(変換しない宛先)は RFC 1918 等のプライベートアドレス範囲とリンクローカルアドレスで、ip-masq-agent の設定で対象 CIDR を追加・変更できる。この agent が DaemonSet として自動デプロイされるか、その既定設定がどうなるかは GKE のバージョンやクラスタ構成(Autopilot か Standard か、Dataplane V2 の有無等)によって異なる。
- IP 許可リスト
- 許可した IP 範囲からのみアクセスを受け付ける組織設定。GitHub ホスト型の送信元 IP は変動するため、固定が要れば larger ランナーの静的 IP やセルフホストを併用する。
- ipconfigとtracert
- Windows環境の基本的なネットワーク診断コマンド。ipconfigは自機のIPアドレス等の設定を表示・更新し(/allで詳細、/releaseと/renewでDHCP再取得)、tracertは宛先までの経路上のルーターを1ホップずつ表示する(Linux/macOSのtracerouteに相当)。
- iperfとスピードテスト
- ネットワーク性能の実測ツール。スピードテストはブラウザ等から特定のサーバーとの間の速度を手軽に測る一方、iperfは自分で用意した2点間(クライアントとサーバー)でスループットを詳細に測定できるオープンソースツールで、障害の切り分けに使える。
- IPsec
- IPパケット単位で暗号化と認証を行うプロトコル群。サイト間VPN(オンプレとクラウドVNet/VPCの接続)で経路を暗号化するのに使われ、両端の暗号化・整合性・鍵交換の設定が一致していないとトンネルが確立しない。
- IPsecのトランスポートモードとトンネルモード
- IPsecのカプセル化形態。トランスポートモードは元のIPヘッダを維持しペイロード部のみを保護するため、主に端末間(ホスト間)通信に用いる。トンネルモードは元のIPパケット全体(ヘッダ含む)を新たなIPヘッダで包んで保護するため、拠点間VPN(ゲートウェイ間)で経路上のアドレス秘匿にも使える。
- iptables/firewalld(ファイアウォール)
- ホストのパケットフィルタ。iptables はカーネルの netfilter をルールチェーン(INPUT/OUTPUT/FORWARD)で直接制御、firewalld はゾーンとサービス名で管理する高水準ツール(--permanent を付けないと再起動で消える)。既定拒否+必要な口だけ許可が基本。
- IPv4アドレス
- 32ビットで表現されるインターネット層のアドレス。ネットワーク部とホスト部からなり、サブネットマスクまたはCIDR表記(例:/24)でその境界を示す。アドレス枯渇のためNAPTやIPv6併用で運用されることが多い。午前IIではサブネット計算・CIDR集約の基礎として頻出。
- IPv6アドレス
- 128ビットで表現されるインターネット層のアドレス。8つの16ビットフィールドをコロン区切り16進数で表記し、連続する0のフィールドは「::」で1回のみ省略できる。プレフィックス長で表しネットワーク部とインタフェースID(下位64ビット)からなる点がIPv4のサブネットマスクと異なる。
- IPアドレス(ネットワークの基礎)
- ネットワーク上の機器を識別するための番号(NAT環境ではプライベートIPが別組織で再利用されうる)。インターネットで直接使われるグローバルIPアドレスと、組織内など限られた範囲で使われるプライベートIPアドレスがある。
- IP電話
- 音声をIPパケットとしてネットワーク経由でやり取りする電話機。従来の電話網を使わずVoIP技術で通話するため、多くはPoEで電源も同じLANケーブルから受電する。
- IRR(内部収益率)
- 投資案の正味現在価値(NPV)がちょうどゼロになる割引率のことで、その投資が生み出す実質的な収益率を表す指標。IRRが資本コスト(要求収益率)を上回っていれば投資は採算に合うと判断でき、複数案の比較ではIRRが高いほど有利とされる。ただしキャッシュフローのパターンによっては解が複数存在したり、投資規模の違いを反映しにくい場合がある点に注意が必要。
- IsBlank 関数(Power Fx)
- 値が空かどうかを判定する関数。必須入力のチェックや既定値の制御に使う(空文字とは区別される)。
- IServiceEndpointNotificationService
- Dataverse のイベントをサービスエンドポイント(webhook/Azure Service Bus/Azure Event Hub)へ発行するためのサービス。
- ISMS(情報セキュリティマネジメントシステム)
- 組織が情報資産を適切に保護するために、方針の策定からリスクアセスメント、対策の実施、見直し(PDCA)までを体系的に運用する管理の仕組み。国際規格ISO/IEC 27001に基づく認証制度がある。
- ISMS適合性評価制度
- 組織のISMSがISO/IEC 27001の要求事項に適合しているかを、認定を受けた第三者審査機関が審査・認証する日本の制度。認証取得は取引先や顧客に対する客観的な信頼性の証明として用いられる。
- ISO 26262
- 自動車の電気・電子システムに特化した機能安全の国際規格。IEC61508をベースに自動車分野向けに策定され、危害の程度・発生頻度・回避可能性からASIL(自動車安全度水準)A〜Dを決定し、要求される安全度に応じた開発プロセス・検証手法を規定する。ASIL Dが最も厳格な水準。
- ISO イメージ
- 光学ディスクの内容を1ファイルにまとめたイメージ形式。Linux のインストールメディアとして配布され、DVD や USB に書き込むか仮想マシンに直接マウントして起動する。
- ISR(割込みサービスルーチン)
- 割込み発生時にハードウェアによって呼び出される専用の処理ルーチン。応答性を確保するため実行時間を最小限に留め、時間のかかる処理は通常タスク側へ委譲する設計が定石とされる。ISR内でリエントラントでない関数を呼んだり長い処理を行うと、他の割込みやタスクの応答性を悪化させる。
- Issue
- バグ・要望・タスクを1件ずつ追跡・議論する機能。Label/Assignee/Milestone と連携。
- Issue テンプレート
- 新規 Issue 作成時に見せる定型のひな形。Markdown ベースの旧形式に加え、YAML で入力フォーム(テキスト欄・選択式・チェックボックス等)を定義できる Issue フォームがあり、必須項目や自動ラベル付与を指定して起票内容を標準化する。`.github/ISSUE_TEMPLATE/` に配置する。
- ITF(統合テスト施設法)
- 本番環境の中に監査用の架空の実体(ダミーの部門・取引先・口座など)をあらかじめ設け、監査人が用意した検証用データを実際の本番取引に紛れ込ませて処理させ、その結果を検証するCAATの一技法。本番運用と並行して継続的に処理の正確性を確認できるが、本番データへの影響を排除する仕組みが必要となる。
- ITIL
- ITサービスマネジメントにおけるベストプラクティスをまとめたフレームワーク。インシデント管理や変更管理などサービス運用の進め方を体系化する。最新のITIL 4(2019年)では、価値共創を中心とする「サービスバリューシステム(SVS)」と34の「プラクティス」に再構成されている(従来のプロセス群はプラクティスとして継承)。
- ITIL4の7つの指針原則
- あらゆる状況で適用できるITIL4の行動指針で、価値に着目する・現状からはじめる・フィードバックをもとに反復して進化する・協働し可視性を高める・包括的に考え取り組む・シンプルにして実践的にする・最適化し自動化するの7つから成る。組織の目的や構造に依存せず普遍的に使える。サービスマネージャは改善や意思決定の場面でこれらを判断の拠りどころとし、過剰設計や局所最適を避ける。
- ITILの4つの側面
- サービスと価値を効果的に成立させるために欠かせない4つの観点で、組織と人材・情報と技術・パートナと供給者・バリューストリームとプロセスから成る。どれか一つでも欠けるとサービスの価値が損なわれるため、全側面をバランスよく点検する必要がある。サービスマネージャは新サービスや改善の検討時に、技術だけでなく人材や供給者、業務の流れまで漏れなく評価する。
- ITサービス継続管理(ITSCM)
- ITSCM(ITサービス継続管理)は、災害や大規模障害などの事態が起きても、合意したRTO(目標復旧時間)およびRPO(目標復旧時点)の範囲内でサービスを復旧できるよう、継続計画の策定・維持・演習を行う活動で、事業継続計画(BCP)の一部を担う。復旧手段・代替設備・優先復旧順序を事前に定め、定期的な演習で計画の実効性を検証する。ITサービスマネージャは事業影響度分析に基づいて復旧目標を定め、投資と復旧速度の均衡を判断する。
- ITへの対応(内部統制の要素)
- J-SOX実施基準がCOSOの5要素に追加した6番目の構成要素。内部統制の目的を達成するために、業務で利用するIT環境(IT基盤・IT業務処理統制・IT全般統制)に組織が適切に対応することを指す。監査人はIT全般統制(アクセス管理・変更管理等)とIT業務処理統制の両面から評価する。
- IT全般統制とIT業務処理統制
- IT統制のうち、アクセス管理・変更管理・運用管理などシステム全体に共通する基盤的な統制がIT全般統制、個々の業務システムにおける入力・処理・出力の正確性を担保する統制(入力チェック・照合・承認など)がIT業務処理統制。IT全般統制が有効でないと、個々のIT業務処理統制の信頼性評価も揺らぐという依存関係にある。
- IT投資ポートフォリオ
- 複数のIT投資案件を、戦略との整合性・リスク・期待リターンなどの観点で分類し、限られた予算の中で組み合わせを最適化する管理手法。基幹業務の維持に不可欠な投資と、新規事業創出を狙う攻めの投資など性質の異なる案件を同一の評価軸で比較しないことがポイントとなる。ITストラテジストは事業部門から上がる複数の投資要求を俯瞰し、経営戦略への貢献度とリスクのバランスを踏まえて優先順位を判断する。
- IT統制
- 内部統制を情報システムの面から支える仕組みで、業務が正しく安全に行われるようITで管理・制御すること。アクセス権限の管理や変更管理などシステム全体に共通する統制と、入力チェックや照合など個々の業務処理の正確さを守る統制からなる。
- J-SOX(内部統制報告制度)
- 金融商品取引法に基づき、上場企業の経営者が財務報告に係る内部統制の有効性を自己評価して内部統制報告書を作成し、公認会計士等による監査を受ける制度。経営者はトップダウン型のリスクアプローチに基づき、財務的重要性の高い項目から評価範囲を絞り込む。監査人は経営者評価の妥当性を検証する。
- JIS Q 20000とサービスマネジメントシステム(SMS)
- サービスマネジメントシステム(SMS)は、サービスマネジメントの方針・目的・計画・プロセスを体系化した仕組みで、PDCAサイクルで運用・改善する。JIS Q 20000-1はSMSに対する要求事項を定めた規格で、第三者認証の基準となる。ITILがベストプラクティス集であるのに対し、JIS Q 20000は満たすべき要求事項という位置づけの違いがあり、サービスマネージャは両者を目的に応じて使い分ける。
- JIS Q 21500
- プロジェクトマネジメントの手引きを示す日本産業規格(JIS Q 21500:2018、ISO 21500:2012に対応)。5つのプロセス群(立上げ・計画・実行・監視コントロール・終結)と10の対象群(知識エリア)でプロジェクトマネジメントの実践を体系化し、PM試験(午前II)の出題体系の基準となる。なおISO 21500は2021年改訂でガバナンス標準に再編され、プロセスの詳細はISO 21502に移行したが、IPA試験は従来のプロセス群/対象群の枠組みを踏襲している。
- JIT(ジャストインタイム生産方式)
- 必要なものを、必要なときに、必要な量だけ生産・調達する生産管理方式。過剰在庫や仕掛品の無駄を排除して生産効率を高めることを目的とし、後工程が必要な分だけ前工程から引き取る「かんばん方式」が代表的な実現手段である。
- join meeting issues(会議参加の問題)
- サインインは成功しているにもかかわらず、会議に参加できない、または参加後に機能(音声・映像・画面共有等)が使えない不具合。ロビーの待機設定、会議ポリシー、ネットワーク/クライアント側の問題など会議・クライアント層が原因となる。CQD や Teams クライアントログで診断する。
- JOIN(INNER/LEFT/RIGHT/FULL/CROSS)
- 複数の表を結合して問い合わせる句。INNER JOIN は両表で条件が一致する行のみ、LEFT JOIN は左表の全行と一致した右表の行、RIGHT JOIN はその逆、FULL JOIN は一致有無に関わらず両表の全行、CROSS JOIN は条件なしの直積を返す。
- JPCERT/CC
- 日本国内におけるコンピュータセキュリティインシデントの報告受付・対応支援・注意喚起を行う一般社団法人。特定の政府機関や企業から独立した中立の調整機関として、国内外のCSIRT間の情報連携のハブも担う。
- JPEGとMPEG
- JPEGは静止画(写真など)を非可逆圧縮する代表的な画像フォーマット。MPEGは動画(映像+音声)を圧縮する代表的な規格群で、フレーム間の差分を利用してデータ量を削減する。
- JSON
- 波括弧とキー・値のペアで構造化データを表す軽量なテキスト形式。API のリクエスト/レスポンスや IAM ポリシー・バケットポリシーのような権限定義など、機械可読性を重視する場面で広く使われる。
- JTAG/ICE(インサーキットエミュレータ)
- JTAGはチップ内部のレジスタ・メモリへ外部からアクセスするための標準デバッグ用シリアルインタフェース規格。ICEはターゲットのCPUを模擬・制御しながら実機上でブレークポイント設定やメモリ/レジスタの読み書きを行うデバッグツールで、多くはJTAG経由で接続する。ソースコードレベルのデバッガが使えない実機環境でのファームウェア検証に不可欠。
- Just-In-Time VM アクセス
- Defender for Cloud の機能で、VM の RDP/SSH などの管理ポートを普段は閉じておき、要求・承認時のみ一時的に NSG/Firewall へ許可規則を入れて開放、時間が経つと自動で閉じる。常時公開を避けて攻撃面を減らす。常時利用できる踏み台の Bastion とは異なり、JIT は「必要なときだけ開ける」方式。
- JVN(Japan Vulnerability Notes)
- JPCERT/CCとIPAが共同で運営する、日本国内で使われるソフトウェア等の脆弱性情報とその対策情報を公開するポータルサイト。CVE番号との対応や深刻度(CVSS)も併記され、脆弱性対応の一次情報として参照される。
- k-means クラスタリング
- 教師なしで、データを k 個のクラスタに分ける代表的手法。各点を最寄りの重心へ割り当て→重心更新を反復する。k はエルボー法/シルエットで選ぶ。スケールに敏感なので標準化が前提。顧客セグメンテーション等に使う。
- Kerberos認証
- 鍵配布センター(KDC)が発行するチケットを用いるチケットベースの認証プロトコル。利用者は一度認証を受けてチケットを取得すれば、以後は各サービスにチケットを提示するだけでよく、パスワードをサービスごとに送信しないシングルサインオン的な利用ができる。
- Key Vault のオブジェクト(キー/シークレット/証明書・開発)
- コードからシークレット・キー・証明書を安全に取得して使う開発。接続文字列等はアプリに直書きせず、Key Vault 参照やマネージド ID で取得する。
- KGIとKPI
- KGI(重要目標達成指標)は最終的に達成すべき経営目標の数値、KPI(重要業績評価指標)はKGI達成に向けた過程を測る中間指標。KPIを継続的に測定することでKGI達成の進捗を管理する。
- Kinesis Data Streams
- 耐久性のあるストリーミング取り込み。データを一定期間保持して再処理(リプレイ)でき、シャードで並列化し、複数の独自コンシューマーが同じストリームを読める。
- Kinesis のコンシューマー(拡張ファンアウト/KCL)
- Kinesis Data Streams の読み取り側。標準コンシューマーはシャードのスループットを共有。拡張ファンアウト(Enhanced Fan-Out)は各コンシューマーに専用 2MB/s を割り当て低遅延化。KCL(Kinesis Client Library)はチェックポイントや負荷分散を担う。
- Kiro
- AWS の「エージェント型 IDE」。仕様(spec)から設計・実装・テストを AI エージェントが進める開発体験を提供し、生成 AI を使ったソフトウェア開発を支援する。
- KMS のキーポリシーとグラント
- KMS キーへのアクセスはキーポリシー(リソースベース・最終的な権限の源)で制御し、IAM ポリシーやグラント(一時的・プログラム的な委任)と組み合わせる。マルチリージョンキーで複数リージョンに複製できる。
- KMS 暗号化コンテキスト
- 暗号化時に指定する追加の鍵と値のペア。復号時に同じコンテキストを要求することで「正しい文脈でのみ復号できる」拘束を与え、CloudTrail にも記録されて監査性が上がる。S3・Secrets Manager 等が内部的に利用する。
- KMS 鍵の種類とローテーション
- KMS の鍵区分。AWS マネージドキー(サービスが自動管理・自動年次ローテーション)/カスタマー管理キー(ポリシー・ローテーション・無効化を自分で制御)/AWS 所有キー(不可視)。グラントとキーポリシーで利用を許可し、自動キーローテーションで鍵素材を更新する。
- Knowledge Bases の複数ソース統合
- 1 つの知識ベースに S3・Web クローラ・データベース等の複数ソースを統合取り込みし、横断検索できる構成。ソースごとにメタデータを付与してフィルタやアクセス制御を効かせ、出典の異なる根拠を一貫して扱う。
- KQL ジョブ(Data lake)
- Data lake 階層の大量データに対し、対話実行ではなくバッチ的に大規模な KQL クエリを実行して結果を保存する仕組み。安価な Data lake で広く探索したいときに使う。
- KQL(Kusto Query Language)
- ログ/時系列データを高速に検索・集計する読み取り専用のクエリ言語。Eventhouse/KQL データベースで使う。
- kubectl
- Kubernetes / GKE クラスタを操作する標準のコマンドラインツール。Pod や Service などのリソースを管理する。
- KVM
- Linux カーネルに組み込まれた仮想化機能(Kernel-based Virtual Machine)。Linux 自身をハイパーバイザーにする。
- KVS(キーバリューストア)
- キーと値の組だけでデータを管理するシンプルな NoSQL データモデル。スキーマレスで水平スケールしやすく、セッション管理やキャッシュなど読み書きが単純で高速性が求められる用途に向く。
- L2スイッチ
- MACアドレスに基づきデータリンク層でフレームを転送するスイッチで、MACアドレステーブルの学習・参照によりポート単位でフレームを中継する。IPアドレスやルーティングを扱わず同一ネットワーク(同一サブネット・VLAN)内の転送に限られ、異なるネットワーク間の通信にはL3スイッチやルータが必要となる。VLANやSTPの実装単位でもある。
- L2ループ
- スイッチ間を冗長経路で接続した際にSTP等のループ防止機構が働かないと発生する、レイヤ2ネットワーク上の経路ループ。ブロードキャストフレームが宛先MACアドレスなしにループ上を無限に増幅・循環するブロードキャストストームや、MACアドレステーブルの不安定化を引き起こし、ネットワーク全体を機能不全に陥らせる。
- L3スイッチ
- L2スイッチの高速な物理・データリンク層処理に、ネットワーク層のルーティング機能を統合したスイッチで、VLAN間ルーティングなどをハードウェア(ASIC)処理により高速に行う点がソフトウェアルーティング中心のルータと異なる。1台でVLANの作成とVLAN間の中継を完結できるため、大規模LANの基幹(コア)スイッチとして広く用いられる。
- Lambda MCP サーバ
- AWS Lambda で MCP(Model Context Protocol)のツールを公開するサーバ実装。軽量・ステートレスなツール(検索・計算・API 呼び出し)をサーバーレスで提供し、エージェントから標準形で呼べる。需要追従でスケールしコスト効率が高い。
- Lambda のバージョンとエイリアス
- 発行したバージョンは不変で、エイリアスが特定バージョンを指す可変ポインタ。エイリアスの加重ルーティングでカナリア/線形のトラフィック移行を行う。
- Lambda の呼び出しモデル(同期/非同期/ストリーム)
- 同期呼び出し=結果を待つ(API Gateway 等)。非同期呼び出し=キューに入れ後で実行、失敗は自動リトライ+デッドレターキュー/送信先(Destinations)。ストリーム/ポーリング=イベントソースマッピング(SQS/Kinesis)。失敗時の扱いがモデルで異なる。
- Lambda の構成(レイヤー・環境変数・一時ストレージ)
- 共通ライブラリはレイヤーで共有し、設定は環境変数(KMS で暗号化可)で渡す。/tmp の一時ストレージは最大 10GB まで拡張でき、メモリ設定が CPU 割り当ても決める。
- Lambda の実行設定(メモリ/タイムアウト//tmp)
- メモリ割り当て(128MB〜10GB・増やすと CPU も比例して増え高速化/低コスト化することも)。タイムアウト(最大15分)。一時ストレージ /tmp(最大10GB)。これらの調整が性能とコストを左右する。
- Lambda 同時実行(プロビジョンド/予約済み)
- Lambda の同時実行制御。プロビジョンド同時実行=実行環境を事前に温めてコールドスタートを抑える。予約済み同時実行=関数ごとに同時実行数の上限を確保/制限する。メモリを増やすと CPU も比例して増える。
- LAN・WAN・PAN(ネットワークの規模)
- ネットワークは規模で分類され、LAN(構内ネットワーク)は自宅やオフィスなど限られた範囲、WAN(広域ネットワーク)は地理的に離れた拠点間を結ぶ範囲、PAN(パーソナルエリアネットワーク)はBluetoothなど個人の身の回り数メートルの範囲を指す。
- larger ランナー
- より大きな CPU/メモリや静的 IP 範囲を持つ GitHub ホスト型ランナー。固定 IP が必要な場合や高負荷ジョブに使う。
- LICENSE
- 利用・改変・再配布の条件を定めるファイル。無い公開リポジトリは既定で全権利留保。
- LISP(Locator/ID Separation Protocol)
- SD-Accessの制御プレーンで使われるプロトコル。エンドポイントの「誰か」を表すEID(Endpoint Identifier)と「どこにいるか」を表すRLOC(Routing Locator)を分離し、マッピングシステムに問い合わせてEIDに対応するRLOCを解決することで、端末が移動してもIDを変えずに到達性を維持できる。
- LLDP(Link Layer Discovery Protocol)
- IEEE 802.1ABで標準化された、ベンダーに依存しない隣接機器発見プロトコル。CDPと同様に隣接デバイス情報をL2で交換するが、Cisco機器以外の異機種混在環境でもトポロジ把握に使える点が異なる。
- LLM-as-a-Judge
- 別の基盤モデルを「評価者」として用い、生成出力の品質(関連性・事実性など)や公平性を大規模かつ一貫して自動採点する手法。重要な判断は人手評価で補完する。
- locate/updatedb
- locate は updatedb が事前に作った索引データベースを検索するため高速だが、索引が古いと新規ファイルは出ない。updatedb で最新化し、除外パス等は /etc/updatedb.conf で設定する。確実性が要る場合は実走査の find を使う。
- Log Analytics ワークスペース
- 各種リソースのログ・メトリックを集約して保持するデータストア。KQL(Kusto Query Language)でクエリして分析でき、Microsoft Sentinel や Azure Monitor アラートの土台にもなる。ワークスペース単位でアクセス制御と保持期間(既定30日、延長可)を設定する。
- Log Replay Service(LRS)
- SQL Managed Instance への移行で、バックアップを Blob から継続的に復元・適用してオンライン移行を実現する手動カットオーバー方式の仕組み。
- logrotate
- テキストログのローテーション・圧縮・削除を自動化する仕組み。全体設定 /etc/logrotate.conf +パッケージごとの /etc/logrotate.d/ で「週次・4世代・圧縮」などを定義し、定期実行される。
- Looker
- 分析結果をダッシュボードで可視化し、ビジネスでの活用を支えるビジネスインテリジェンス(BI)。
- Looker Studio
- 手軽にレポートやダッシュボードを作成・共有できる可視化(BI)ツール。
- LookML
- Looker でデータのメトリクスやディメンションを定義するモデリング言語。指標の一貫性を保つ。
- LookUp 関数(Power Fx)
- 条件に一致する最初の 1 件のレコード(または列の値)を返す関数。単一レコードの取得に使う。
- LoRA(低ランク適応)
- 少数の追加パラメータだけを学習してモデルをドメイン適応させる、パラメータ効率の良い微調整手法。フルのファインチューニングより低コスト。
- LPWA(LoRa/NB-IoT)
- 低消費電力で数km〜十数kmの長距離通信を実現する無線通信技術の総称。データレートは低いが、電池のみで数年間駆動しながら広域をカバーできるため、位置情報の追跡や環境センサなど、低頻度・小容量データを広範囲から収集するIoT用途に適する。LoRaは免許不要帯域を使う独自プロトコル、NB-IoTは携帯電話網(セルラー)を利用する規格という違いがある。
- LSA(Link State Advertisement)
- OSPFルータが自身に接続するリンクの状態(インタフェース・コスト・接続先等)を広告する情報単位。全ルータから収集したLSAの集合がリンクステートデータベース(LSDB)を構成し、各ルータはこれを基にSPFアルゴリズムで最短経路木を計算する。LSAの種類(Type 1〜等)によって広告範囲や内容が異なる。
- lspci/lsusb
- 接続デバイスを確認するコマンド。lspci は PCI デバイス(NIC・GPU 等)、lsusb は USB デバイスの一覧。ハードウェアが物理的に認識されているかの確認に使う。
- LTV(顧客生涯価値)
- 一人の顧客が取引開始から終了までの期間に自社にもたらす利益の総額。新規顧客の獲得コスト(CAC)と比較することで、マーケティング投資の妥当性や、既存顧客の維持・関係深化にどこまで投資すべきかを判断する指標として用いる。継続率や購入頻度・単価を高める施策はLTVを押し上げ、CACの回収期間の短縮にもつながる。
- lv 系コマンド(論理ボリューム操作)
- LVM で論理ボリューム(LV)を扱うコマンド群。lvcreate で VG から LV を切り出し、lvextend/lvresize で拡張、lvdisplay/lvs で確認する。
- LVM(論理ボリューム管理)
- 物理ディスク(物理ボリューム PV)を束ねてボリュームグループ VG にし、そこから論理ボリューム LV を切り出す抽象層。稼働中の動的拡張・縮小や、ある時点を凍結するスナップショットができる。
- M&Aとアライアンス(戦略的提携)
- M&A(合併・買収)は他社の経営権を取得して自社に統合することで、事業や技術を短期間で獲得する成長手段。アライアンス(戦略的提携)は資本関係を伴わない、あるいは一部出資にとどめた協力関係で、双方が独立性を保ちながら特定領域で協業する。ストラテジストは、スピードと統合コスト・リスクの大きいM&Aと、柔軟だが統制が効きにくいアライアンスのどちらが目的達成に適するかを、獲得したい経営資源の性質や統合の必要度に応じて判断する。
- MACsec(IEEE 802.1AE)
- IEEE 802.1AEで規定される、スイッチ間やスイッチ-端末間などL2のホップ単位でフレームを暗号化・認証する規格。IPsecがL3のエンドツーエンドまたはサイト間で暗号化するのに対し、MACsecは隣接するリンク1本ごとに保護をかける点が異なり、リンクの盗聴・改ざん・なりすましを防ぐ。
- MACアドレス
- データリンク層でネットワークインタフェースを一意に識別する48ビットの物理アドレスで、上位24ビットのOUI(製造者識別子)と下位24ビットの製造者内シリアル番号から成る。IPアドレスのように経路によって変化せず機器に固定されている点が特徴で、同一データリンク(L2セグメント)内でのフレーム転送先の特定に用いられる。
- MACアドレステーブルとMACアドレスフィルタリング
- MACアドレステーブルはL2スイッチが学習した「MACアドレスとポートの対応」を記録する表で、これに基づきフレームを該当ポートへ転送する。MACアドレスフィルタリングはポートごとに許可するMACアドレスを制限し、未登録の機器の接続を拒否するアクセス制御手段。
- MACアドレス学習
- L2スイッチが受信フレームの送信元MACアドレスと受信ポートの対応をMACアドレステーブル(FDB)に動的に記録する機能で、以降その宛先MACアドレス宛のフレームは該当ポートへのみ転送される。学習前や未学習の宛先の場合はフラッディングでフレームを送出する。一定時間参照されないエントリはエージングアウトにより削除される。
- MAN・CAN(都市規模・構内規模ネットワーク)
- ネットワークの規模による分類のうち、MAN(メトロポリタンエリアネットワーク)は都市規模、CAN(キャンパスエリアネットワーク)は大学や企業の複数建物にまたがる構内規模のネットワークを指す。LANより広くWANより狭い中間的な規模を表す用語として使われる。
- man(マニュアル)
- コマンドのオンラインマニュアルを表示する(man ls)。man -k キーワード(=apropos)でキーワードから関連コマンドを探せる。
- managed Google Play
- 組織用の Google Play ストアを Intune に統合し、公開アプリの承認・配布に加え社内限定の private app も配布できる仕組み。Android Enterprise の登録(fully managed / work profile 等)と組み合わせて使い、アプリの自動更新やアプリ設定(app configuration)も一元管理する。
- Managed Instance のデータベースコピー/移動
- SQL Managed Instance 間でデータベースをコピー(複製)または移動(移管)するネイティブ操作。インスタンス再編成や環境分離に使う。
- Managed Service for Apache Flink
- ストリームをその場でウィンドウ集計・変換するリアルタイム処理サービス。低遅延の連続的なストリーム分析に使う。
- managed ソリューション
- テストや本番環境へ配布する、読み取り専用(ロック)状態のソリューション。管理設定でコンポーネントの編集可否を細かく制御でき、アンインストール(削除)が可能な単位として扱われる。unmanaged から直接編集はできず、変更は開発環境で行って再エクスポートする。
- Markdown
- 軽い記法で書式を表す記法(.md)。Issue・PR・コメント・README で広く使う。
- Marketplace アプリ / サードパーティアプリ管理
- Google Workspace Marketplace のアプリや、OAuth で接続するサードパーティアプリへのアクセスを統制する。アプリ単位の許可/ブロック、API アクセス管理(アプリアクセス制御)、未構成アプリの信頼/制限設定で不正な連携を防ぐ。
- max_locks_per_transaction
- サーバ全体で保持できる共有ロックテーブルの容量を決めるパラメータ。スロット数は (max_connections + max_prepared_transactions) × max_locks_per_transaction で見積もられる。大量のテーブルやパーティションに同時アクセスするトランザクションが多い環境で不足すると「out of shared memory」エラーの原因になる。
- max_parallel_workers
- クラスタ全体でパラレルクエリに使えるワーカープロセスの総数上限を定めるパラメータ。個々のクエリが使える並列度の上限は max_parallel_workers_per_gather で別途制限される。
- max-parallel
- matrix の同時実行数の上限。コストとランナー枠を調整するために使う。
- MCP(Model Context Protocol)
- LLMアプリケーションとツール/データソースの接続方法を標準化するオープンプロトコル。従来は連携先ごとに個別の統合コードが必要だったが、MCPサーバーとして公開すればどのMCP対応クライアント(エージェント)からも共通の形式で呼び出せる。AWSではLambda等で実装したツールをMCPサーバーとして公開する構成が使われる。
- MCRA(Microsoft Cybersecurity Reference Architectures)
- Microsoft 製品がどの防御能力を担うかを ID/SOC/エンドポイント/ハイブリッド・マルチクラウド/OT 等にわたり体系化した参照アーキテクチャ。設計の出発点・能力ギャップ把握に使う「地図」で、適合を測る MCSB とは役割が異なる。
- MDM(モバイルデバイス管理)とパッチ管理
- MDM(モバイルデバイス管理)は組織が配布・許可したスマートフォンやタブレットに対し、暗号化強制・リモートワイプ・アプリ制限等のセキュリティポリシーを一元適用する仕組み。パッチ管理はOSやソフトウェアの脆弱性修正パッチを計画的に検証・展開し、既知の脆弱性が悪用される窓を短くする継続的な運用活動。いずれもハードニング・資産管理と並ぶ基礎的なセキュリティ管理活動。
- Meet の会議ポリシー
- 会議の録画の可否、外部参加者やホスト管理などの参加者制御を OU/グループ単位で定める設定。
- Memorystore
- Redis / Memcached 互換のフルマネージドなインメモリキャッシュ。頻繁な読み取りをキャッシュしてレイテンシを下げる。永続ストアではない。
- Merakiとネットワーク管理システム
- Meraki(Cisco Meraki)はクラウドから一元管理できるCisco製ネットワーク機器群のブランドで、専用ダッシュボードから複数拠点の設定・監視をまとめて行える。ネットワーク管理システム(NMS)は、こうしたスイッチ・ルーター・APなどのネットワーク機器の状態監視・設定・障害検知を一元的に行うソフトウェアの総称。
- merge(マージ)
- 両者の履歴を保ったまま、マージコミットで統合する方法。経緯が残る。
- MFA デバイスの種類
- 多要素認証の第2要素。仮想 MFA(認証アプリの TOTP)/ハードウェア MFA(物理トークン)/FIDO セキュリティキー(パスキー・フィッシング耐性が高い)。ルートと特権ユーザーには必須。重要操作は aws:MultiFactorAuthPresent 条件で強制する。
- MFA 登録キャンペーン
- ユーザーに、より強い認証方式(Microsoft Authenticator 等)の登録を促す機能。SMS など弱い方式から段階的に移行させる。強制ブロックではなくナッジ。
- Microsoft 365
- メール・文書・会議などをクラウドで提供する SaaS の生産性スイート。ユーザー単位のサブスクリプションで利用する。
- Microsoft 365 Apps の展開
- クライアント版 Office(Word/Excel 等)をクリックツーランで配信・更新する仕組み。更新チャネル(現在/月次エンタープライズ/半期)で更新頻度を制御する。
- Microsoft 365 Backup
- Exchange / SharePoint / OneDrive のデータを誤削除や破損から高速に復元できる保護。長期保持の Purview retention(コンプライアンス保持)とは目的が別。
- Microsoft 365 Copilot
- Word・Excel・Outlook・Teams などのアプリに組み込まれた AI アシスタント。ユーザーが既にアクセスできるデータの範囲内でのみ動作し、新たなアクセス権は作らない。利用には別途ライセンスが必要。
- Microsoft 365 グループ
- 複数サービス(Teams・SharePoint・Outlook・Planner 等)に共通のメンバーシップとリソースを提供する基盤。1 つのグループで横断的に共同作業できる。
- Microsoft 365 のライセンス(ユーザー単位サブスク)
- ユーザー(座席)単位でライセンスを契約し月額/年額で支払う。プランは Business/Enterprise/Frontline 等。割り当ては Microsoft 365 管理センター。AWS/Azure の従量課金とは別。
- Microsoft 365 の購入経路
- Microsoft 365/Azure ライセンスを調達する経路の分類。Enterprise Agreement(EA・大規模組織向けの複数年契約)、クラウドソリューションプロバイダー(CSP・パートナー経由で柔軟な月次契約や請求代行)、Web Direct(Microsoft から直接オンラインで購入)の3系統があり、組織規模とサポート要件で選ぶ。
- Microsoft 365 ライセンスモデル(E3/E5/Business)
- 規模と機能で選ぶプラン。中小向けの Business(Basic/Standard/Premium)、大企業向けの Enterprise(E3/E5・E5 は高度なセキュリティ/分析)、現場ワーカー向けの F シリーズがある。
- Microsoft 365 管理センター
- Microsoft 365 全体の中心的な管理ポータル。ユーザー・ライセンス・グループ・ドメイン名・組織設定を管理し、各ワークロード専用の管理センターへの入口にもなる。Copilot のライセンス割り当てや利用状況レポートもここから行う。
- Microsoft Agent Framework
- 単一エージェントの応答だけでは対応しきれない複雑なワークフローを実装するためのオープンソースのオーケストレーションフレームワークで、Semantic Kernel と AutoGen を統合した後継にあたる。マルチエージェント連携(役割分担・引き継ぎ)、複数ユーザーとの並行セッション、human-in-the-loop(人の承認)を挟むワークフローと自律実行の両方を含む柔軟なタスク制御をコードで組み立てる。Foundry Agent Service で個々のエージェントを作り、本フレームワークでそれらを束ねて動かす関係。
- Microsoft Authenticator
- スマートフォンアプリによる多要素認証・パスワードレスサインインの方式。プッシュ承認に番号一致(number matching)を組み合わせ、誤承認や MFA 疲労攻撃を抑える。SMS より強く、passkeys(FIDO2)に次ぐ実用的な方式。
- Microsoft Azure(Power Platform 連携)
- Microsoft のクラウド基盤。Power Platform はより高度な開発や AI・データ連携(Azure Functions、API Management、Azure OpenAI など)で Azure とつながる。
- Microsoft Clipchamp
- 動画を編集・作成する Microsoft 365 のアプリ。テンプレートや録画機能を備える。
- Microsoft Cloud Security Benchmark(MCSB)
- Defender for Cloud が既定で評価する Microsoft のセキュリティベストプラクティス集。セキュアスコアの基準となり、業界フレームワークにマッピングされる。
- Microsoft Copilot
- Microsoft 365・Windows・GitHub などに組み込まれた、すぐ使える生成AIアシスタント。
- Microsoft Copilot Studio(旧 Power Virtual Agents)
- ローコードでチャットボット/対話アシスタントを作るツール(支援=assist)。会話はトピック(意図ごと)で構成し、生成AIナレッジや Power Automate と連携できる。
- Microsoft Cost Management
- 実際の支出を可視化・分析し、予算とアラートを設定する。Pricing Calculator(事前見積り)とは別。
- Microsoft Dataverse
- Power Platform の安全で構造化されたデータストア(テーブル)。型・リレーションシップ・きめ細かいセキュリティを備え、Excel/SharePoint リストより業務データ向き。モデル駆動型アプリの土台。
- Microsoft Defender for AI services
- Microsoft Defender for Cloud のクラウドワークロード保護プランの一つ(正式名 Microsoft Defender for AI services・旧称 Defender for AI workloads)。AI ワークロードへの実行時の脅威(プロンプトインジェクションの試行・資格情報の不正利用・機微データの抜き取り等)を検知してアラートする。態勢可視化は「データと AI のセキュリティ」ダッシュボードで行う。
- Microsoft Defender for Cloud
- リソースのセキュリティ状態を採点(セキュアスコア)し、設定不備や脅威を検出して改善を促す。
- Microsoft Defender for Cloud Apps
- クラウドアプリの利用やシャドー IT を可視化・制御する CASB(クラウドアクセスセキュリティブローカー)。
- Microsoft Defender for Endpoint
- デバイス(エンドポイント)の EDR/保護を担う製品。オンボード→エンドポイント設定→脆弱性管理の順で導入する。メール保護の Defender for Office 365 とは別。
- Microsoft Defender for Office 365
- メール/コラボの脅威保護。脅威ポリシー(anti-phishing/spam/malware)・Safe Attachments・Safe Links・Threat Explorer・攻撃シミュレーションを提供する。デバイス EDR の Defender for Endpoint とは別。
- Microsoft Defender Threat Intelligence
- 脅威アクター・IOC・脅威分析レポートなど外部脅威情報を提供し、観測した痕跡を既知の攻撃と突き合わせる。自作 KQL の advanced hunting とは別。
- Microsoft Defender XDR
- 端末/メール/ID/SaaSアプリの防御を統合し、領域横断でシグナルを相関して検知・対応する(Endpoint/Office 365/Identity/Cloud Apps)。
- Microsoft Defender ポータル
- Defender XDR の各シグナル(メール・ID・エンドポイント・アプリ)を統合し、インシデント調査・対応・Secure Score を一元管理する管理ポータル。
- Microsoft Dynamics 365
- 営業・カスタマーサービス・財務などの業務アプリ群。Dataverse を共通基盤とするため、Power Platform とデータ・拡張を直接共有できる。
- Microsoft Editor
- スペル・文法・文体の改善を提案する校正支援機能。Word やブラウザで使える。
- Microsoft Entra Agent ID
- 自律的に行動する AI エージェントに ID を付与し、条件付きアクセスでアクセスを統制する仕組み。侵害時の影響範囲(ブラスト半径)は Defender XDR で分析し、アクセスを最小化・無効化する。
- Microsoft Entra Application Proxy
- オンプレの Web アプリを VPN なしで安全に外部公開し、Entra 認証+事前認証を前段に置く仕組み。Global Secure Access の Private Access は、Web 以外のプロトコルにも対応する発展形。
- Microsoft Entra Cloud Sync
- オンプレ AD を Entra へ同期する軽量方式。軽量なプロビジョニングエージェントを複数配置でき高可用、複数フォレストや断片化した AD に向く。単一の高機能エージェントの Connect Sync と使い分ける。
- Microsoft Entra Connect Health
- 同期/認証エージェント(Connect Sync・PTA・AD FS 等)の稼働状況・エラー・パフォーマンスを監視するサービス。ハイブリッド ID 基盤の健全性を可視化する。
- Microsoft Entra Domain Services
- ドメインコントローラを自分で管理せずにドメイン参加・グループポリシー・従来認証を提供するマネージドドメインサービス。Azure Virtual Desktop ではセッションホストの ID シナリオの一つで、自前の AD DS とクラウドネイティブな Entra ID 参加の中間に位置する。
- Microsoft Entra hybrid join
- オンプレミス Active Directory に参加済みのデバイスを、Entra Connect の同期を通じて Entra ID にも参加させ、両方の認証局を持たせる方式。オンプレのグループポリシー(GPO)と Intune/Conditional Access を並行運用したい移行期の組織や、オンプレ AD 依存のレガシーアプリが残る環境で使われる。
- Microsoft Entra ID
- クラウドのID/アクセス管理サービス(旧Azure AD)。MFA・SSO・条件付きアクセスを提供。オンプレのAD DSとは別物。
- Microsoft Entra ID Protection
- 漏洩資格情報やあり得ない移動などからユーザーリスク/サインインリスクを算出し、条件付きアクセスと連携する。
- Microsoft Entra Internet Access
- Global Secure Access(SSE)の一部。ユーザーのインターネット/SaaS 行きの通信をセキュア Web ゲートウェイとして検査・制御し、クロステナント保護も行う。社内アプリへの ZTNA を担う Entra Private Access とは送信先で区別する。
- Microsoft Entra join
- 組織が所有するデバイスを Microsoft Entra ID にクラウドネイティブで完全参加させる方式。デバイスは Entra ID のみを認証局とし、Intune による自動登録(自動 MDM 登録)でフル管理下に置ける。オンプレミス AD には参加させない、クラウドのみの組織や新規デバイス向けの既定選択肢。
- Microsoft Entra Kerberos
- ハイブリッド ID 向けに、Entra 参加デバイスから Kerberos 依存のオンプレリソース(ファイル共有等)へシングルサインオンを可能にする仕組み。
- Microsoft Entra Permissions Management
- Microsoft の CIEM 製品。マルチクラウド(Azure/AWS/GCP)の ID とリソースにまたがる権限を分析し、Permission Creep Index(権限の肥大度を示すスコア)で可視化、未使用権限の是正案を提示する。単一のダッシュボードで複数クラウドの実効権限を横断把握できる点が特徴。
- Microsoft Entra Private Access
- VPN に代わり、社内アプリへ ID ベース・アプリ単位(ゼロトラスト)でアクセスを提供する。ネットワーク全体ではなく必要なアプリだけに到達させる。
- Microsoft Entra パスワード保護
- グローバル/カスタムの禁止パスワードリストで、弱い・推測されやすいパスワードを拒否する機能。オンプレ AD にも拡張でき、クラウドとオンプレで一貫したパスワードポリシーを適用する。
- Microsoft Fabric ミラーリング(Cosmos DB)
- Cosmos DB のデータを Microsoft Fabric の OneLake へ near-real-time にミラーし、Fabric で分析する機能。バッチ志向の Cosmos DB Spark コネクタと使い分ける。
- Microsoft Fabric(容量・ワークスペース・エクスペリエンス)
- データ統合・分析・BI を 1 つに統合した SaaS 分析基盤。階層は「容量(キャパシティ)→ ワークスペース → アイテム」。容量=コンピュート+課金の単位(F SKU・Power BI Premium の P SKU、容量ユニット CU を消費、スムージング/バースティングで平準化、一時停止/再開可)。ワークスペース=コラボとアクセス管理の単位。エクスペリエンス=Data Engineering/Data Factory/Data Warehouse/Real-Time Intelligence/Power BI など役割別機能。全エクスペリエンスが OneLake を共有する点が最大の特徴。PaaS の寄せ集めではなく統合 SaaS。
- Microsoft Forms
- アンケートやクイズを作って回答を集めるツール。回答をトリガーに Power Automate を起動し、Dataverse 保存や通知に連携できる。
- Microsoft Foundry のハブとプロジェクト
- 生成 AI 開発の土台。ハブベース構成ではハブが共有リソース・接続・セキュリティ・コスト管理を束ね、その下のプロジェクトが個別の作業領域とモデル/フローを管理する。2025年以降はハブ不要の Foundry プロジェクト(軽量・単体)構成も選べる。
- Microsoft Graph PowerShell
- Entra/Microsoft 365 を自動化するための PowerShell モジュール。旧 AzureAD/MSOnline モジュールの後継で、属性更新やライセンス割当などの反復処理をプログラム的に実行する。
- Microsoft Graph アクティビティログ
- テナントに対する Graph API の呼び出し(どのアプリ/ユーザーがどのリソースに API アクセスしたか)を記録するログ。OAuth アプリの悪用や API 経由の不審なアクセスの調査に使う。認証イベントを記録するサインインログとは別物。
- Microsoft Graph とグラウンディング
- Copilot は Microsoft Graph を通じてメール・ファイル・チャット・予定などの組織コンテキストにアクセスし、ユーザーの権限を尊重した上で関連情報を取り込んで応答を生成する(グラウンディング)。アクセス権の範囲が応答の範囲を決める。
- Microsoft Identity Platform
- アプリのサインインとトークン取得を担う認証基盤。アプリ登録を行い、MSAL ライブラリで OAuth2/OIDC のトークンを取得してリソースにアクセスする。
- Microsoft Intune
- デバイスとアプリを管理・保護するクラウドサービス。MDM=端末そのものを管理、MAM=アプリ内データを管理。条件付きアクセスと連携。
- Microsoft Lists
- 情報やタスクをリスト形式で追跡・管理するアプリ。テンプレートやビュー、ルールで業務データを整理する。
- Microsoft Power BI
- データをレポート(複数ページの対話分析)やダッシュボード(1画面の要約)で可視化・共有する BI ツール。
- Microsoft Power Pages(旧 Power Apps ポータル)
- ローコードで外部公開向けの Web サイト/ポータルを作る Power Platform の製品。データは Dataverse に保存し、外部ユーザーは匿名/要サインインと権限でアクセス制御する。社内業務アプリの Power Apps と役割が対になる(外部公開=Power Pages)。
- Microsoft Power Platform
- ローコード/ノーコードで分析・アプリ・自動化・対話を実現する Microsoft のプラットフォーム。市民開発者でも業務改善できる。M365/Dynamics 365/Azure と連携。
- Microsoft Priva
- 個人データのプライバシーリスク管理と主体権利要求(DSR)への対応を支援するソリューション。過剰な個人データの保持や共有を検出・是正する。
- Microsoft Project
- 大規模プロジェクトのスケジュール・依存関係・リソースを管理する本格的なプロジェクト管理ツール。
- Microsoft Purview
- データガバナンスとコンプライアンスを統合した Microsoft の管理ソリューション群。情報保護・データライフサイクル・リスク管理・eDiscovery・監査に加え、データマップ/カタログによる横断的なデータガバナンスを含む(旧 Azure Purview を統合)。
- Microsoft Purview データ損失防止(DLP)
- 機密情報が組織外へ漏えいするのを防ぐ機能。Exchange Online/SharePoint Online/OneDrive/Teams のワークロードに DLP ポリシーを適用し共有/送信をブロック・ポリシーヒントで警告する。分類の label・保持の retention とは別。
- Microsoft Search
- 人・ファイル・サイト・メールを横断して検索する統合検索。各アプリの検索ボックスから利用する。
- Microsoft Secure Score
- 組織のセキュリティ態勢を数値化し、推奨される改善アクションと達成度を示す指標。Microsoft Defender ポータルで確認する。
- Microsoft Security Copilot
- セキュリティ運用(SecOps)に生成 AI を活用するツール。ワークスペース(容量=SCU)と権限・ロールで構成し、プラグインでデータソース/製品に接続、Microsoft/Security Store エージェントで SecOps タスクを半自律実行する。ユーザーの既存権限の範囲内で最小特権に統制する。
- Microsoft Security Exposure Management
- ID/エンドポイント/クラウド/データを統合し、外部の入口から重要資産への到達経路(攻撃パス)を可視化する。致命的な経路上のチョークポイントを優先的に塞ぐ posture プロセスを支える。
- Microsoft Sentinel
- クラウドネイティブな SIEM+SOAR。各所のログを収集し脅威を検知・調査・自動対応する。
- Microsoft Sway
- デザイン性の高いニュースレターやプレゼンテーションを手軽に作成・共有するアプリ。
- Microsoft Teams
- チャット・会議・通話・チームワークを集約したコラボレーションのハブ。ファイルは裏で SharePoint/OneDrive に保存。
- Microsoft Teams Network Assessment Tool
- 実際にメディア トラフィックを送ってパケット損失・遅延・ジッターを実測し、ネットワークが Teams に適しているか評価するツール。事前計画の Network planner とは別。
- Microsoft Teams Rooms
- 会議室に設置する専用の Teams デバイス。リソース メールボックスのアカウントとシステムを構成し、firmware を更新する。
- Microsoft To Do
- 個人のやること(タスク)を管理するアプリ。Planner や Outlook のタスクと同期する。
- Microsoft Tunnel
- Intune 標準の Linux ベース ゲートウェイ VPN(追加費用なし)で、MDM 登録済みデバイスへ安全なアクセスを提供する。未登録デバイス(BYOD)を MAM のみで管理しつつアプリ単位のアクセスを行うには、別途 Intune Suite / MAM アドオンの Microsoft Tunnel for Mobile Application Management(Tunnel for MAM)が必要で、こちらが App protection policy と連携し社内リソースへの接続を業務アプリに限定する。
- Microsoft Visio
- フローチャートや組織図・ネットワーク図などを作成する作図アプリ。
- Microsoft Viva
- 学習・インサイト・エンゲージなど従業員エクスペリエンスを高めるプラットフォーム(リアルタイム会話の Teams とは別カテゴリ)。
- Migration Evaluator
- オンプレミス環境を AWS へ移行する際の、根拠に基づくコスト見積もり(ビジネスケース)を作成する無料の評価サービス(旧 TSO Logic)。現状のサーバー使用状況を収集し、AWS 移行後の費用と削減効果を可視化して移行判断を支える。
- Milestone
- リリースや期限の単位で Issue/PR をまとめ、達成率や期限を可視化する機能。
- MITRE ATT&CKフレームワーク
- MITRE社が公開している、実際の攻撃で観測された戦術(Tactics)・技術(Techniques)・手順(Procedures、まとめてTTP)を体系的に整理したナレッジベース(マトリクス)。防御側は自組織の検知・対応がどの技術をカバーしているかを可視化するために使う。
- MITRE CAPEC
- MITREが公開する、攻撃パターン(Common Attack Pattern Enumeration and Classification)を体系的に分類・列挙したナレッジベース。攻撃者の手口を共通の分類で扱えるようにし、脅威分析やセキュリティ設計の参照に用いられる。
- ML データ準備(エンコード/スケーリング/不均衡)
- 生データをモデルが学べる形に整える工程。エンコード=カテゴリを数値化(ワンホット/順序/ターゲット)、スケーリング=標準化(z-score)/正規化(Min-Max)、不均衡=SMOTE等のオーバーサンプリング/クラス重み付け(評価はF1/PR-AUC)。変換のfitは分割後のトレーニングデータのみ(データリーク防止)。
- MLflow トラッキング
- Azure ML にネイティブ統合された実験管理。log_metric/log_param/log_artifact や autolog で学習を記録し、実行を比較する。
- MLmodel ファイルとシグネチャ
- MLflow モデルのメタデータファイル。入力/出力スキーマ(シグネチャ)やフレーバーを記述し、必要なら特徴量取得仕様をモデル成果物に同梱する。
- MLOps(SageMaker Pipelines / Model Registry)
- MLライフサイクルを再現可能・自動・統制された形で回す。Pipelinesは処理→学習→評価→登録/デプロイをDAGで自動化、評価ステップ+条件で品質ゲート。Model Registryはモデルをバージョン管理し承認ステータスで本番デプロイを統制。CodePipeline等のCI/CDやEventBridgeで再学習を自動化。
- MMU/MPU(メモリ保護)
- MMU(メモリ管理ユニット)は仮想アドレスを物理アドレスへ変換しプロセスごとにメモリ空間を分離する。MPU(メモリ保護ユニット)は仮想化は行わず、物理アドレス上にサイズやアラインメント(2の冪等)に制約はあるが設定可能な複数の保護領域を設けてアクセス権限(読み書き実行)を制限する、ページテーブル不要の軽量な仕組み。組込みではMMUのオーバーヘッドを避けつつ暴走時のメモリ破壊を防ぐため、リアルタイム性重視のMCUではMPUが多用される。
- Model Garden
- Google 製・オープン・サードパーティの多様な基盤モデルを一覧から選んで使える Vertex AI のカタログ。
- MOT(技術経営)
- 技術に立脚する事業を行う企業が、技術開発の成果を事業成果や企業価値の向上へ継続的に結び付けていくためのマネジメント手法。
- MPLS
- パケットにラベルを付与し、網内のルータがIPヘッダを都度解析せずラベルに基づいて高速転送するラベルスイッチング技術。IP-VPNサービスの基盤として、共有網でありながら顧客ごとの経路を分離し、拠点間の任意接続を効率的に提供する。
- MRP(資材所要量計画)
- 製品の生産計画と部品表(BOM)をもとに、いつ・何を・どれだけ調達/製造すべきかを逆算して算出する生産管理手法。需要予測に基づく見込み生産で在庫の過不足を防ぎ、部品や資材の発注タイミングを最適化する。ITストラテジストは受注生産に近いJIT/かんばん方式との使い分けを、業種や生産形態の特性を踏まえて判断する。
- MSDP(Multicast Source Discovery Protocol)
- 複数のPIM-SMドメイン(それぞれ独自のRPを持つ)にまたがってマルチキャストの送信元情報を共有するプロトコル。あるドメインのRPは自ドメイン内の送信元しか知らないため、MSDPピアを介して他ドメインのRPへ送信元の存在を通知し合うことで、ドメインをまたいだ受信者が別ドメインの送信元からのマルチキャストを受信できるようにする。
- MST(Multiple Spanning Tree)
- 複数のVLANを少数のスパニングツリーインスタンスにまとめて動作させるIEEE 802.1s規格。VLANごとに個別のSTPインスタンスを持つPVST+と異なりCPU負荷を抑えられる。異なるスイッチが同じMSTリージョンに属すには、リージョン名・リビジョン番号・VLAN-インスタンス対応表の3要素が完全に一致している必要がある。
- MTA とメール転送(aliases/.forward)
- メールを受け取り配送するサーバーソフトが MTA(postfix・exim。SMTP 25番)。システム全体の転送は /etc/aliases に書き、編集後は必ず newaliases で反映する。ユーザー個人の転送は ~/.forward。送信は mail、配送待ちキューの確認は mailq。
- MTU とジャンボフレーム
- 経路上で送れる最大パケットサイズ。VPC 内は最大 9001(ジャンボフレーム)、IGW/VPC ピアリング経由は 1500、Transit Gateway は 8500、Site-to-Site VPN は最大 1500(IPsec で実効はさらに小さい)。DF ビット付きで小さい MTU を越えるとパス MTU 探索の ICMP(Fragmentation Needed)が必要で、これを SG/NACL で塞ぐと接続はできるのに大きな転送だけ固まる典型障害になる。
- MTUとMSS
- MTU(最大転送単位)は、データリンク層が1フレームで運べる上位層データ(IPパケット)の最大サイズ(例:イーサネットは1500バイト)。VPN等のカプセル化で追加ヘッダーが付くと実効MTUが縮小し、大きなパケットで断片化・再送が増え特定アプリだけ遅くなることがある。MSS(最大セグメントサイズ)はTCPが1セグメントで送るデータ上限で、トンネル分を見込んで調整すると断片化を避けられる。
- multitenant organization(MTO)
- 複数のテナントを 1 つの組織として統合的に運用する構成。shared channels(チャネル単位の協働)とは目的が異なる。
- MVCC(多版同時実行制御)
- 更新のたびに行の複数バージョンを保持し、各トランザクションが開始時点のスナップショットを読むことで、読み取りが書き込みをブロックしない(また逆も)並行制御方式。ロックベースの方式より高い並行性を実現し、多くの現代的な DBMS の既定の隔離実装に使われる。
- MVCとObserverパターン
- MVC(Model-View-Controller)はデータ(Model)・画面表示(View)・処理の受け渡し(Controller)を分離してコードの見通しと保守性を高める設計パターン。Observerパターンはある対象(Subject)の状態変化を、登録された複数の監視者(Observer)へ自動的に通知する設計パターンで、イベント駆動の仕組みの基礎になる。
- MX レコード
- ドメイン宛のメールをどのメールサーバーへ配送するかを指定する DNS レコード。優先度(プリファレンス値)を複数設定でき、値が小さいほど優先される。Google Workspace ではドメイン検証後に MX を Google のメールサーバーへ向けることでメール受信が有効になる。
- NAC(ネットワークアクセス制御)
- 機器がネットワークに接続する際に、セキュリティ状態(パッチ適用状況・ウイルス対策ソフトの有無等)を確認し、基準を満たさない機器を隔離または制限したうえで接続を許可する仕組み。
- NAPT(IPマスカレード)
- プライベートIPアドレスの複数端末が、ポート番号の変換を併用して1つのグローバルIPアドレスを共有してインターネットへ接続する技術。IPアドレスとポートの対応表で通信を管理する。ESP(プロトコル番号50・ポート番号を持たない)はそのままでは変換できず、IPsec VPNではNAT-Tでの対処が必要になる。
- NAT インスタンス vs NAT ゲートウェイ
- プライベートサブネットの外向き通信を仲介する2方式。NAT ゲートウェイ=マネージド・高可用(AZ 内冗長)・自動スケール(推奨)。NAT インスタンス=EC2 を自前運用(送信元/宛先チェック無効化が必要・単一障害点・安価/特殊用途)。
- NAT-T(NATトラバーサル)
- NAPT配下からIPsec VPNを確立するための仕組み。ポート番号を持たないESPパケットはNAPTで変換できないため、IKEネゴシエーション時にNAPTの有無を検出し、ESPをUDP(一般にポート4500)でカプセル化してNAPT機器が通常のUDP通信として変換・転送できるようにする。
- NAT(ネットワークアドレス変換)
- プライベート IP アドレスをパブリック IP アドレスへ、またはその逆へ変換する仕組み。ルータやゲートウェイで動作し、組織内の多数の端末が少数(または1つ)のパブリック IP を共有してインターネットへ出られるようにする(NAPT/IPマスカレード)。Linux では iptables の MASQUERADE ターゲット等で実現する。
- Natural Language API
- 文章の感情やエンティティを分析する事前学習済みの API。レビューの感情分析などに使う。
- needs(ジョブ依存)
- ジョブの実行順を制御するキー。needs: [A, B] で「A と B の完了後に実行」を宣言する。前段ジョブの outputs 参照経路でもある。
- NETCONF・RESTCONF・YANG
- YANGは機器の設定・状態をleaf/list/containerの階層で定義するデータモデリング言語。NETCONFはSSH上でXMLメッセージを使い、YANGモデルに基づく設定をcandidate/runningといったデータストア単位でトランザクション的に投入するプロトコル。RESTCONFはHTTP+JSON/XMLでYANGモデルへアクセスし、GET/POST/PUT/PATCH/DELETEをCRUD操作に対応させる、より馴染みやすいプロトコル。
- NetFlow
- ルーターやスイッチが通過したトラフィックを、5-tupleを鍵にしたフロー単位の統計情報(バイト数・パケット数・開始終了時刻等)として出力する技術。パケット全体は保存しないため軽量で、大規模な通信傾向の把握や異常検知に向く(トランザクションデータの代表例)。
- Network Access Analyzer
- パケットを流さずに構成だけを静的解析し、「本来到達できてはいけないリソースに到達できる経路」がないかをスコープ定義で洗い出すサービス。意図しないネットワーク露出(過剰なオープン経路)の検出に使う。到達可否と遮断箇所の特定は Reachability Analyzer、傾向監視は CloudWatch と役割が分かれる。
- Network Connectivity Center(NCC)
- ハブにスポーク(VPC/ハイブリッド/プロデューサ)を接続し、多数のネットワークの到達性を中央管理するサービス。VPC ピアリングが非推移なのに対し、NCC はハブ&スポークで推移的な到達性を実現する。
- Network connectivity insights
- 各拠点から Microsoft 365 への接続経路(最適な egress・レイテンシ)を評価して改善する機能。Microsoft 側の障害を表示する Service Health とは別。
- Network Firewall のステートフルルール
- VPC のサブネット境界でトラフィックを検査する。ステートレスルール(高速な許可/拒否)とステートフルルール(コネクション追跡・Suricata 互換シグネチャでドメイン/プロトコル検査)。送信ドメインフィルタリングや IPS に使う。
- Network Intelligence Center
- ネットワークの可視化・診断・最適化ツール群。Network Topology(可視化)、Connectivity Tests(経路/ファイアウォールの静的診断)、Performance Dashboard(パケットロス/レイテンシ)、Firewall Insights、Network Analyzer(自動の構成診断)、Flow Analyzer を含む。
- Network Load Balancer(NLB)
- L4 の超高性能ロードバランサ。固定 IP(AZ ごと)を持ち、クライアント IP を保持でき、クロスゾーン負荷分散や PrivateLink のサービス公開に使う。
- Network planner
- 拠点・ペルソナ・ネットワーク サイトを入力し、Teams 展開前に必要帯域と影響を事前にモデル化する計画ツール。実メディアで品質を実測する Network Assessment Tool とは別。
- Network Service Tiers
- ネットワークの性能/コストの選択。Premium(Google バックボーン・グローバル・高性能)と Standard(コスト重視・リージョン)。
- Network Watcher 診断ツール(IP フロー検証・接続モニター・ネクストホップ)
- ネットワークの可視化・切り分けを行う Network Watcher の診断ツール群。IP フロー検証=特定の送信元/宛先/ポートが NSG で許可/拒否されるか(一致した規則名つき)を即判定。接続モニター=エンドポイント間の到達性・遅延・パケットロスを継続監視。ネクストホップ=あるパケットの実際の次ホップを表示し UDR の誤りを切り分ける。NSG/VNet フローログ=通過/拒否トラフィックを Storage に記録し Traffic Analytics で可視化。ほかにパケットキャプチャ・接続トラブルシューティング・トポロジ。「NSG で止まっている?経路の問題?」に応じて道具を選ぶ。
- NFV(ネットワーク機能仮想化)
- FW・ロードバランサ・ルータ等の専用ハードウェアアプライアンスが担っていた機能を、汎用サーバ上の仮想化ソフトウェア(VNF)として実装する技術。専用機の個別調達を不要にし、機能を需要に応じてソフトウェア的に増減できる。経路制御のプレーン分離を扱うSDNとは目的の軸が異なる。
- NIST SP 800-61とNIST SP 800-86
- NIST SP 800-61はインシデント対応(準備→検知・分析→封じ込め・根絶・復旧→事後活動)のライフサイクルを定めるガイドライン。NIST SP 800-86はフォレンジックにおける証拠収集の手順(揮発性の高い順に収集する等)・完全性の保全・保管方法を定めるガイドライン。両者は補完関係にあり、IRの現場ではSP 800-61の手順の中でSP 800-86の証拠取得基準が適用される。
- NORフラッシュ/NANDフラッシュ
- いずれも不揮発性メモリだが特性が異なる。NORフラッシュはアドレス単位のランダムアクセスが可能でCPUが直接実行(XIP)できるため主にプログラム格納に、NANDフラッシュは大容量・低コストだがブロック単位の書換えでランダムアクセスが遅く、主にデータ格納に使われる。用途に応じた選定と、書換え寿命に配慮した設計が要る。
- NotAction
- Action の代わりに使える要素で、「リストした操作を除くすべて」を対象にする。Allow と組み合わせると意図せず広範な許可になりやすく、Deny と組み合わせる場合に限定的に使うのが安全とされる。対になる NotResource も同様の注意が要る。
- NotebookLM
- ユーザーが与えた資料(ソース)に根ざして要約・質問応答を行い、出典に基づいた回答を返す調査支援ツール。
- Notify 関数(Power Fx)
- 画面上部に通知メッセージ(成功/エラー/情報)を表示する関数。保存完了や入力エラーの通知に使う。
- NPV(正味現在価値)
- 投資によって将来得られるキャッシュフローを一定の割引率で現在価値に割り引いて合計し、そこから初期投資額を差し引いた金額。NPVが正(NPV>0)であればその投資は採算が取れると判断され、複数の投資案がある場合はNPVが最大の案を選ぶのが基本原則。金額そのもので投資規模の違いを反映した絶対評価ができる点が回収期間法との違い。
- NSG のセキュリティ規則
- NSG のインバウンド/アウトバウンド規則。優先度順に評価し、送信元/宛先(IP・ASG・サービスタグ)・ポート・プロトコルで許可/拒否する。既定規則は最後に評価される。
- NSG の評価と有効なルール
- NSG はサブネットと NIC の両方に適用でき、優先度の低い番号から評価して最初に一致したルールで許可/拒否する。有効なセキュリティ規則で実際の適用結果を確認する。
- nslookup
- 指定したドメイン名に対応するIPアドレス(またはその逆)をDNSサーバーに問い合わせて表示するコマンド。名前解決がうまくいかない障害の切り分けや、不審なドメインの調査に使う。
- NSレコード
- あるゾーンを管理する権威ネームサーバのホスト名を示すDNSリソースレコード。親ゾーンに置かれたNSレコードは子ゾーンへの委任を表し、当該ゾーン自身にも同一内容のNSレコードを置くことで一貫性を保つ。Aレコードによる正引きとは異なり、名前解決の権限所在を示す点が本質。
- NTP(時刻同期・chrony)
- ネットワーク経由で時刻源と同期するプロトコル(UDP 123・pool.ntp.org)。常駐デーモンが徐々に補正(slew)する ntpd/後継の chronyd(管理は chronyc)を使い、稼働中の時刻の急変(特に逆行)を避ける。ntpdate は一回きりの合わせで非推奨。確認は ntpq -p/chronyc sources。
- NTPストラタム
- NTPで時刻の権威(正確さの階層)を表す番号。原子時計やGPS等の基準時刻源に直結するサーバがストラタム0/1で、そこから時刻を受け取るごとにストラタム番号が1つずつ増える。クライアントはより小さいストラタム値のサーバを、より信頼できる時刻源として優先的に選ぶ。
- NULL 値・欠損の解決
- NULL や欠損・重複を、除外・既定値の代入・集約などで扱う品質対策。分析結果の正しさに直結する。
- null_frac / n_distinct
- pg_stats の列統計。null_frac はその列に含まれるNULL値の割合、n_distinct はその列の重複を除いた個別値の推定数(正の値は絶対数、負の値は行数に対する比率の目安)を表す。
- OAuth App
- ユーザーに代わって(on behalf of the user)GitHub にアクセスする連携方式。認可時にユーザーが持つ権限の範囲でスコープ(scope)を選び、そのユーザーの権限を借りて動作するため、GitHub App のようなリポジトリ単位の細かい権限指定はできない。個人の手軽なトークンである PAT(Personal Access Token)とも区別される。
- OAuth(認可フレームワーク)
- 利用者に代わって第三者アプリがリソースへアクセスする権限を、パスワードを渡さずにアクセストークンとして委譲する「認可」フレームワーク。認証(本人確認)そのものを行う仕組みではない点に注意(認証にはOpenID Connectを重ねる)。
- OCR(Read)
- Azure AI Vision の Read 機能で、印刷・手書きのテキストを画像やドキュメントから抽出する光学文字認識。
- ODFC(Office Container)
- Office/Outlook のデータ(OST・検索インデックス・Teams キャッシュ等)だけを別コンテナに分離する FSLogix の機能。プロファイル全体を運ぶ Profile Container と併用し、Office 体験を高速化する。
- Office 365 Users コネクタ
- 組織のユーザープロフィール(上司・部署・連絡先)を取得するコネクタ。承認者の決定やプロフィール表示に使う。
- Office Deployment Tool(ODT)
- Microsoft 365 Apps(Office)のクリックツーラン形式のインストール内容を、XML 構成ファイルで細かく制御するコマンドライン ツール。含めるアプリ・言語・更新チャネル・除外コンポーネントを指定してカスタムパッケージを作り、Intune の Win32 app や配布共有経由で展開できる。
- Office アプリ(Word/Excel/PowerPoint/Outlook)
- 文書・表計算・プレゼン・メールの中核アプリ。Microsoft 365 ではサブスクで常に最新版を Web/デスクトップ/モバイルで使え、共同編集も可能。
- Office モバイルアプリ
- iOS/Android で Word・Excel・PowerPoint などを使うモバイルアプリ。
- OIDC フェデレーション(CI/CD)
- 外部 CI(GitHub Actions 等)が長期アクセスキーなしで AWS のロールを引き受ける仕組み。IAM に OIDC ID プロバイダーを登録し、信頼ポリシーで sub(リポジトリ/ブランチ)を限定して AssumeRoleWithWebIdentity で一時認証情報を得る。キーレスで安全。
- OLA(運用レベル合意)
- 同一組織内の運用チームや内部部門どうしで結ぶ合意で、SLAで顧客に約束したサービスレベルを裏で支えるための内部目標を定める。たとえば復旧時間や対応時間を内部部門間で取り決め、それらの積み上げがSLA目標を満たすよう設計する。サービスマネージャは顧客向けSLAを起点にOLAの目標を逆算し、内部の責任分担と整合をとる。
- OLAP(分析処理)
- 履歴データを対象に大量読み取り・集計を行う分析向けワークロード。データウェアハウスに対し実行。
- OLTP(トランザクション処理)
- 小さな読み書きを多数・高速に処理する業務向けワークロード。ACID で取引の正しさを保証。
- on:(トリガー宣言)
- ワークフローを起動するイベントを宣言するキー。push・pull_request・schedule・workflow_dispatch・repository_dispatch・workflow_call などを指定する。
- OneDrive
- 個人のクラウドファイル保存と同期。自分のファイルを保管し必要に応じて共有する(SharePoint は組織共有)。
- OneDrive for Business コネクタ
- 個人のクラウドファイル(OneDrive for Business)にファイルを保存・取得するコネクタ。フローでの添付保存などに使う。
- OneLake
- 組織で 1 つに統合された Fabric のストレージ(ADLS Gen2 互換・テーブルは Delta 形式)。全エクスペリエンスが共有し、データを 1 か所に集約する。
- OneLake カタログ
- 組織の OneLake 上のデータ(アイテム)を検索・把握し、信頼性(エンドース)や系列を確認できるデータ発見の入口。
- OneLake ショートカット
- 内部/外部(ADLS Gen2・Amazon S3・GCS など)のデータを、コピーせず OneLake から参照する仕組み。重複保存を避けデータを仮想的に統合する。
- OneLake セキュリティ
- OneLake のデータに対するアクセス制御。OneLake データアクセスロールでフォルダー/テーブル単位の権限を定義し、全エンジンに一貫適用する。
- OP25B(Outbound Port 25 Blocking)
- 動的IPアドレス帯や一般端末セグメントから外部の25番ポート(SMTP)への直接接続を遮断する迷惑メール対策。正規のメール送信はサブミッションポート(587番)+SMTP-AUTHに限定し、感染端末による直接送信(踏み台化)を防ぐ。
- Open API 定義(Swagger)
- REST API の操作/パラメーター/応答を記述する仕様。カスタムコネクタの定義に使う。実行時の挙動を変えるポリシーテンプレートとは役割が異なる。
- OpenSearch Serverless(ベクトルエンジン)
- プロビジョニング不要で k-NN ベクトル検索を提供する OpenSearch。Bedrock Knowledge Bases の既定のベクトルストアとして使われ、埋め込みの近似最近傍探索で関連チャンクを高速取得する。Aurora pgvector や Pinecone 等が代替。
- OpenTelemetry
- ベンダー中立なテレメトリ(メトリクス・ログ・トレース)の計装標準。アプリを一度計装すれば各種バックエンドへ送れる。分散トレースの計装にも使う。
- OpEx(運用支出)
- 使った分だけ継続的に支払う支出。クラウドの従量課金はこのモデルで、初期投資を抑え需要に応じて費用を伸縮できる。CapExからOpExへの転換はクラウド移行の主要な財務メリットとして語られる。
- Ops Agent
- Compute Engine や オンプレミス VM にインストールし、詳細なシステムメトリクス(CPU/メモリ/ディスク等)とログを Cloud Monitoring / Cloud Logging へ収集するエージェント。旧来の Monitoring エージェントと Logging エージェントを統合したもので、新規はこちらを使う。
- OPTIMIZE(テーブル最適化)
- 小さなファイルを大きなファイルへ統合し、読み取りを速くする Delta の保守コマンド。small files 問題の定番対処。
- org-wide app settings
- テナント全体でサードパーティ/カスタム アプリの利用可否の大枠を決める設定。個別制御のポリシーとは別レイヤー。extensibility はタブ/メッセージング拡張/会議内アプリ/ワークフロー。
- Organization
- 複数のメンバーとリポジトリを一元管理する組織アカウント。Team・課金・権限を持つ。
- Organization service(IOrganizationService)
- .NET SDK でサーバーサイド/プラグインから Dataverse を CRUD 操作する API。クライアントの Dataverse Web API と区別する。
- ORマッピング(O/Rマッピング, インピーダンスミスマッチ)
- オブジェクト指向のオブジェクトと関係データベースのテーブルとの間の構造的な差異(インピーダンスミスマッチ)を吸収し、両者を対応づける仕組み。クラスと表、属性と列、参照や継承と外部キーなどを機械的に変換し、ORマッパー(ORM)がこの変換を自動化する。システムアーキテクトはオブジェクトモデルとデータモデルの整合を保ちつつ、性能への影響を見極めてマッピング方針を判断する。
- OS Login
- VM への SSH アクセスを IAM と連携して一元管理する仕組み。鍵を個別配布するより安全。
- OS(オペレーティングシステム)の役割
- ハードウェアとアプリケーションソフトウェアの間に位置し、メモリ管理・タスク管理・ファイル管理・入出力制御などを担う基本ソフトウェア。アプリケーションはOSが提供する機能を通じてハードウェアを利用する。
- OSI 参照モデル(L3/L4/L7)
- 通信機能を7階層に分けた参照モデル。AWS でよく出るのは L3(ネットワーク=IP・ルーティング)、L4(トランスポート=TCP/UDP・NLB)、L7(アプリケーション=HTTP・ALB/WAF)。ロードバランサや防御の動作層を理解する基礎。
- OSINT(公開情報インテリジェンス)
- 公開されている情報(Webサイト・SNS・登録情報・掲示板等)を収集・分析して得る脅威インテリジェンス。攻撃者の偵察手段でもあり、防御側も自組織の露出情報の把握や脅威動向の収集に活用する。
- OSI参照モデル
- ネットワーク通信の機能を7つの階層(物理層・データリンク層・ネットワーク層・トランスポート層・セッション層・プレゼンテーション層・アプリケーション層)に分けて整理した標準モデル。各層の役割を理解することでプロトコルの位置づけを把握できる。
- OSPF
- リンクステート型のIGP(内部ゲートウェイプロトコル)。各ルータがネットワーク全体のトポロジ情報(LSA)を共有し、リンクの帯域から算出したコストを合計して最小コスト経路を選択する。エリア分割による階層化で大規模ネットワークに対応し、リンクステート型のため経路変化時の収束が速い。既定のアドミニストレーティブディスタンスは110。
- OSPFネットワークタイプ
- OSPFがインタフェースの物理特性に応じて隣接形成の挙動を変えるための分類。イーサネット等のブロードキャストネットワークタイプではDR/BDRの選出が行われるのに対し、シリアル回線等のポイントツーポイントネットワークタイプでは接続相手が1台しかないためDR/BDR選出が行われず、双方が直接フル隣接になる。ネットワークタイプの不一致はHelloパケットの不整合を招き隣接形成を妨げる。
- OSPFルート集約(area range/summary-address)
- OSPFで複数の細かい経路を1つの集約経路にまとめ、経路表のサイズと再計算範囲を抑える設定。area rangeはABR(エリア境界ルータ)でエリア間の集約に使い、summary-addressはASBR(自律システム境界ルータ)で外部経路(再配布された経路)を集約するのに使う。
- OSS のコミュニティとエコシステム
- OSS を支える分散型の開発体制。メンテナー(取り込みの最終判断者)を中心に世界中のコントリビューターがパッチ/プルリクエストを送る。意思疎通はメーリングリスト(LKML 等)・掲示板・開発サイト(イシュートラッカー)。ディストリビューションは上流(アップストリーム)を統合してユーザーへ届ける結節点。
- OSS-DB/PostgreSQL のコミュニティ
- PostgreSQL の開発・議論を支える分散コミュニティ。開発者向けメーリングリスト pgsql-hackers(機能開発・パッチ議論)や pgsql-bugs(バグ報告)で意思疎通し、誰でもバグ報告や議論への参加を通じて貢献できる。
- OSS(オープンソースソフトウェア)
- ソースコードが公開され、一定のライセンス条件のもとで誰でも利用・改変・再配布できるソフトウェア。無償で使えることが多いが、無保証であることが一般的で、利用にはライセンス条件の確認が必要。
- OSコマンドインジェクション
- Webアプリが外部入力を検証せずOSコマンドの一部として実行してしまう脆弱性を悪用し、サーバ上で任意のコマンドを実行させる攻撃。シェルに渡す前の入力検証やコマンド実行APIの安全な利用が対策となる。
- Outlook on the web
- ブラウザから Exchange Online のメール・予定表・連絡先を使う Web 版 Outlook。
- OWASP
- Webアプリケーションのセキュリティ向上を目的とする非営利団体、およびその公開する指針群の総称。代表的な成果物であるOWASP Top 10は実際に多い脆弱性クラスを整理したリストで、2021年版ではA01アクセス制御の不備・A03インジェクション(SQLインジェクションやクロスサイトスクリプティング(XSS)を包含)等が上位に並ぶ(旧版で独立項目だったXSSはA03へ統合、CSRFは単独項目から外れた。以降も定期的に改訂される)。アプリ開発者が優先して対策すべき項目の指標として広く参照される。
- PaaS(Platform as a Service)
- アプリの実行基盤を借りるモデル。OS・ランタイムは事業者が管理し、利用者はアプリとデータに集中(例:App Service)。
- Pacemaker
- Linux 上で SAP HANA や SAP Central Services(SCS)の高可用性クラスタを構成するクラスタソフトウェア。リソースのフェイルオーバーを自動管理する。スプリットブレイン防止に STONITH を組み合わせる。
- PAgP(Port Aggregation Protocol)
- EtherChannelの束ねを自動ネゴシエーションするCisco独自プロトコル。標準規格であるLACPと役割は同じだが、Cisco機器同士でのみ利用でき、モードにはdesirable(能動)とauto(受動)がある。
- Parameter Store
- 設定値や機密(SecureString は KMS 暗号化)を階層的に保存・バージョン管理する Systems Manager のストア。アプリ設定の一元管理に使う。
- PartyRock
- Amazon Bedrock を基盤にした、コード不要で生成 AI アプリを試作できる学習向けの遊び場(プレイグラウンド)。
- passive-interface(OSPF)
- OSPFのインタフェースコマンドで、そのインタフェースからHelloパケットを送出しない(=隣接関係を形成しない)ようにする設定。インタフェースが属するネットワークを経路として広告することは維持したまま、端末が接続されているだけでルータが存在しない区間で不要な隣接形成やHello交換を止め、帯域とセキュリティ面の余計な露出を防ぐ。
- Patch Manager
- パッチベースラインで承認するパッチを定義し、メンテナンスウィンドウの時間枠でフリート全体に適用・コンプライアンスを評価する機能。
- Patch 関数(Power Fx)
- レコードを作成または更新する関数。フォームを使わずにデータソースへ書き込みたいときに使う。
- PATH
- コマンドの実行ファイルを探索するディレクトリの一覧を持つ環境変数。カレントディレクトリは原則含まれないため、その場のスクリプトは ./script.sh(相対パス)か絶対パスで実行する。
- paths / branches フィルター
- push/pull_request の起動対象を絞るフィルター。paths/paths-ignore でファイル、branches/branches-ignore でブランチを指定し、不要な実行を起こさずコストを節約する。
- PBR(Policy-Based Routing)
- 宛先アドレスだけを基準に経路表を参照する通常のルーティングと異なり、送信元アドレス・パケットサイズ・アプリケーション種別等の条件(ポリシー)に基づいてネクストホップや出力インタフェースを上書きするルーティング手法。route-mapで条件と処理を定義し、特定の部門やアプリケーションのトラフィックだけを別回線へ迂回させるといった用途に使う。
- PCF コードコンポーネント
- Power Apps component framework で TypeScript/JS のカスタム UI コントロールを作る仕組み。ライフサイクル init/updateView/getOutputs/destroy、manifest で宣言、package→deploy→consume で配布。canvas/model 両用。
- PCI DSS・HIPAA・GDPR・FERPA・FISMA(コンプライアンス関連法規)
- 特定分野の個人情報・機密データの取り扱いを義務付ける法規制・業界基準。PCI DSSはクレジットカード情報を扱う事業者向けの業界基準、GDPRはEU域内の個人データ保護規則、FERPAは米国の学生教育記録保護法、FISMAは米国連邦政府機関の情報セキュリティ管理法、HIPAAは米国の医療情報保護法。
- PDCAサイクル
- Plan(計画)→Do(実行)→Check(評価)→Act(改善)を繰り返すことで業務やマネジメントを継続的に改善する手法。1周で終わらせず、Actの結果を次のPlanへつなげる点が重要。
- PDU・フレーム・パケット
- 各階層でやり取りされるデータのまとまりをPDU(プロトコルデータユニット)と呼び、階層ごとに呼び名が変わる。データリンク層ではフレーム、ネットワーク層ではパケット、トランスポート層ではセグメントと呼ぶ。
- Performance Analyzer
- Power BI Desktop の機能で、各ビジュアルの DAX クエリ時間や表示時間を計測し、遅いビジュアルを特定する。性能改善の出発点。
- permissions(トークン権限)
- GITHUB_TOKEN に与える権限を宣言するキー。最小権限(contents: read 等)を既定にし、必要なジョブだけ書き込みへ昇格する。OIDC を使う場合は id-token: write を付与する。
- Persistent Disk
- VM に接続するブロックストレージ。ゾーン/リージョン(冗長)や標準/SSD を用途で選ぶ。
- Personal Access Token(PAT)
- 権限・期限・対象を絞れるトークン。Git 操作の認証にパスワード代わりに使う(fine-grained 推奨)。
- PEST分析
- 政治(Politics)・経済(Economy)・社会(Society)・技術(Technology)という4つの外部マクロ環境要因を整理し、事業戦略に与える影響を分析するフレームワーク。ストラテジストは、法規制の改廃や景気動向、人口動態、技術革新といった自社では制御できない環境変化を早期に捉え、SWOT分析の「機会・脅威」を洗い出す前提情報として用いる。
- PFS(前方秘匿性)
- 長期的に保持する秘密鍵(サーバ証明書の秘密鍵など)が将来漏えいしても、過去に記録された暗号化通信を復号できない性質。TLSでDHE/ECDHEのようなセッションごとに使い捨てる一時鍵で鍵合意を行うことで実現される。TLS1.3では標準的に満たされる。
- pg_basebackup
- 稼働中のクラスタから物理的なベースバックアップを取得するツール。ストリーミングレプリケーション接続を使い、レプリケーション用スタンバイの初期構築や PITR の起点取得に使う。裏側で非排他的バックアップの仕組みを利用する。
- pg_cancel_backend()
- 指定バックエンドの実行中クエリのみをキャンセルする関数(セッション自体は継続する)。セッションごと切断したい場合は pg_terminate_backend() を使う(本節の対比対象)。
- pg_config
- インストールされている PostgreSQL のビルド設定情報(インストールパス・コンパイルオプション・バージョンなど)を表示するユーティリティ。拡張モジュールのビルド時などに参照される。
- pg_controldata
- データベースクラスタの制御情報(pg_control ファイル)を表示するユーティリティ。データベースの状態、最新のチェックポイント位置、WAL のバージョンなどを確認できる。
- pg_ctl
- PostgreSQL サーバプロセスを制御するユーティリティ。start/stop/restart/reload/status のサブコマンドで起動・停止・再起動・設定再読み込み・状態確認を行う。
- pg_ctl promote
- スタンバイをプライマリへ昇格させ、以後の書き込みを受け付けられるようにするコマンド。フェイルオーバー時に、レプリケーション遅延が最小のスタンバイを選んで実行するのが定石。同じ昇格操作は SQL 関数 pg_promote() でも実行できる。
- pg_hba.conf
- クライアント認証を制御する設定ファイル。接続元(アドレス・データベース・ユーザー)ごとに認証方式(trust・md5・scram-sha-256・peer など)を行単位で記述し、上から順に評価して最初に一致した行の規則が適用される。
- pg_isready
- PostgreSQL サーバが接続を受け付けられる状態かを確認するユーティリティ。終了コードで稼働状況(受付可・拒否・接続不可・不明)を返す軽量な死活監視用コマンド。
- pg_locks
- 現在保持中・待機中のロックを一覧するシステムビュー(ロックマネージャの現状を示す動的ビューで、pg_stat_* のような累積統計ビューではない)。どのトランザクション(pid)がどのオブジェクトにどんな種類のロックを保持/要求しているかを示し、ロック競合やデッドロック調査の一次情報源となる。
- pg_monitor
- サーバの監視に必要な権限(pg_read_all_settings・pg_read_all_stats・pg_stat_scan_tables を含む)をまとめて付与する定義済みロール。監視ツール専用アカウントに GRANT pg_monitor で最小権限の監視権限を与えられる。
- pg_receivewal
- スタンバイを構築せずにWALストリームだけを継続的に受信・保存する専用ツール。WALアーカイブの代替やニアリアルタイムのWALバックアップに使われる。レプリケーションスロットを使用すると、プライマリ側が未送信のWALを保持し続けるため、一時的な切断があってもWALを欠損なく受信できる。
- pg_reload_conf()
- 再起動不要な設定変更(SIGHUP で反映されるパラメータ)をサーバへ即座に反映させる関数。ただし shared_buffers や max_connections のようにサーバ起動時に確定するパラメータ(PGC_POSTMASTER)は reload では反映されず、サーバの再起動が必要。
- pg_resetwal
- 破損などで起動不能になったデータベースクラスタの WAL やその他の制御情報をリセットして強制的に起動可能にするユーティリティ。データ損失を伴いうる最終手段であり、通常運用では使わない。
- pg_rewind
- 旧プライマリを新プライマリのスタンバイとして再構成するツール。昇格後に分岐した部分だけを新プライマリのデータで上書きするため、ベースバックアップを取り直すより高速。旧プライマリと新プライマリを同時稼働させるスプリットブレインを避けるための正しい再統合手順。
- pg_start_backup() / pg_stop_backup()
- PITR用のオンラインバックアップを開始・終了する関数(Ver12-14で有効。15で廃止され pg_backup_start()/pg_backup_stop() へ改称)。pg_start_backup() はバックアップ開始をサーバへ通知しチェックポイントを強制、pg_stop_backup() はバックアップ終了を通知しラベルファイルとWALの確定を行う。
- pg_stat_activity(wait_event_type/wait_event)
- 現在接続中の各セッションの状態を可視化する統計ビュー。実行中クエリ・状態(state=active/idle/idle in transaction 等)に加え、待機理由を示す wait_event_type(例:Lock)と、より詳細な wait_event(例:transactionid=他トランザクションの確定待ち)を持つ。
- pg_stat_all_tables
- テーブル単位のアクセス傾向を示す統計ビュー。シーケンシャルスキャン回数・読み取り行数(seq_scan/seq_tup_read)、インデックススキャン回数、行の挿入・更新・削除数、最終 ANALYZE 時刻(last_analyze/last_autoanalyze)などを保持し、インデックス不足やメンテナンス頻度の診断に使う。
- pg_stat_archiver
- WAL アーカイブ処理の成否をサーバ全体で集計する統計ビュー(1行のみ)。archived_count(成功累計)、failed_count(失敗累計)、last_failed_time(直近失敗時刻)などを持ち、アーカイブコマンドの失敗を監視してディスク圧迫やレプリケーション遅延の兆候を早期発見するのに使う。
- pg_stat_bgwriter
- バックグラウンドライタの活動をサーバ全体で集計する統計ビュー(1行のみ)。PostgreSQL 17 以降はチェックポイント関連の統計(チェックポイント回数・所要時間等)とバックエンドプロセスが書き出したブロック数(buffers_backend)が新設の pg_stat_checkpointer へ分離されたため、pg_stat_bgwriter は buffers_clean(バックグラウンドライタが書き出したブロック数)・maxwritten_clean・buffers_alloc のみを保持する。PG16以前はチェックポイント統計も本ビューに含まれていた。
- pg_stat_database
- データベース単位の統計を集計するビュー。累積コミット数(xact_commit)・累積ロールバック数(xact_rollback)・デッドロック件数・一時ファイル使用量などを持ち、DB全体のワークロード傾向を把握できる。
- pg_stat_replication
- プライマリ側で参照するレプリケーション監視ビュー。接続中の各スタンバイについて、WAL の送信位置・フラッシュ位置・リプレイ位置と、それぞれの遅延(write_lag/flush_lag/replay_lag)を表示し、レプリケーション遅延の切り分けに使う。
- pg_stat_ssl
- 各バックエンド接続が SSL で暗号化されているか、使用中の暗号方式やプロトコルバージョンなどを確認できる統計ビュー。データそのものの暗号化状況ではなく、通信経路(ワイヤーレベル)の SSL 状態を映す。
- pg_stat_statements
- クエリ単位(定数部分を正規化したクエリ文字列ごと)の累積実行統計を保持する拡張。呼び出し回数・総/平均実行時間・読み取りブロック数などを集計し、どのクエリが最も負荷をかけているかの特定に使う。shared_preload_libraries への登録が必要で、ビューとして提供される統計は pg_stat_statements_reset() でリセットできる。
- pg_stat_wal_receiver
- スタンバイ側で参照するレプリケーション監視ビュー。自身が受信している WAL ストリームの状態(接続先プライマリ・受信済みLSN・接続開始時刻など)を1行で表示し、walreceiver プロセスの状況を確認するのに使う。
- pg_statio_all_tables
- テーブル単位の物理 I/O 内訳を示す統計ビュー。共有バッファでヒットしたブロック数(heap_blks_hit)とディスクから読み取ったブロック数(heap_blks_read)などをテーブル・インデックス・TOAST別に持ち、バッファヒット率が低いテーブルの特定に使う。
- pg_statistic
- プランナが実行計画を選ぶ根拠となる列統計を、内部形式の生データのまま保持するシステムカタログ。ANALYZE 実行で更新され、値は型依存の配列やスカラー等で格納されるため直接読むのは難しく、通常は人間可読なビューの pg_stats を介して参照する。
- pg_stats
- pg_statistic を人間が読みやすい形に整形したビュー。null_frac(NULL の割合)・n_distinct(異なる値の推定数)・most_common_vals(頻出値)・histogram_bounds(分布のヒストグラム境界)・correlation(物理順序との相関)などの列を持ち、実行計画がなぜ選ばれたかの調査で確認する対象。
- pg_xact
- 各トランザクションIDがコミット済みか・ロールバック済みかを記録するコミットログを保持するディレクトリ(旧称 pg_clog)。破損すると行の可視性判定ができなくなり、深刻な障害につながる。
- pgstattuple
- テーブルやインデックスの肥大化・デッドタプル率を詳細調査できる拡張機能。pgstattuple() 関数でページ使用率・空き領域率・デッドタプル比率などを実測でき、VACUUM の要否判断に使う。
- PID制御
- 目標値と現在値の差(偏差)に対し、比例(P)・積分(I)・微分(D)の3要素を組み合わせて操作量を計算するフィードバック制御方式。比例は現在の偏差、積分は過去の偏差の累積(定常偏差の解消)、微分は偏差の変化率(急変への抑制)にそれぞれ対応し、3ゲインの調整(チューニング)で応答性と安定性のバランスを取る。
- PII マスキング(生成 AI)
- 生成AIの入出力やログに含まれる個人情報(PII)のトークンを、他の値に置換・編集(redaction)して秘匿する対策。Amazon Comprehendによる検出結果やBedrock Guardrailsの機密情報フィルタが、プロンプト・応答・ログの該当箇所をマスクし、データ漏えいや規制違反を防ぐ。
- PIM for Groups
- グループのメンバー/所有者を Just-In-Time 化し、グループ経由のアクセスも時間制限つきにする PIM の機能。グループに紐づく特権も常時付与しない。
- PIM の active 割り当て
- PIM でロールを常時有効な状態で割り当てる方式。アクティブ化の操作なしに即座に権限を使えるが、常時高権限を持つため監査上のリスクが高く、通常は eligible 割当が推奨される。時間指定(開始/終了)付き active 割当も設定可能。
- PIM の eligible 割り当て
- PIM でロールを常時付与(active)せず「対象者」として割り当てる方式。ユーザーは必要なときだけ自らアクティブ化し、MFA・正当な理由の入力・(設定により)承認・有効期限つきで昇格する。常時高権限を持たせない最小特権設計の核。
- PIM(Protocol Independent Multicast)
- マルチキャストの配送経路を構築するプロトコル群。PIM-SM(Sparse Mode)は既定でRP(Rendezvous Point)を頂点にした共有ツリーを使ってグループへ配送し、トラフィック量が増えると送信元ごとの最短経路ツリー(SPT)へ切り替えて効率化する。bidir-PIMはRPを介した双方向の共有ツリーのみを使い、多数の送信元がいる環境の状態量を抑える。
- ping/traceroute(疎通・経路調査)
- ネットワーク障害を層ごとに切り分ける道具。ping(ping6)は ICMP で相手まで届くかを確認、traceroute/tracepath は経由ルータを1ホップずつ表示して停止点を特定する。tracepath は特権不要で MTU も調べる。
- PITR(ポイントインタイムリカバリ)
- ベースバックアップとその後の WAL アーカイブを組み合わせて、任意の過去時点までデータベースを復元する仕組み。誤操作や障害の直前まで戻すといった柔軟な復旧を可能にする。
- PKIと認証局
- PKI(公開鍵基盤)は公開鍵とその所有者を結び付け、なりすましを防ぐための仕組み全体。認証局(CA)が公開鍵に電子証明書を発行し、その正当性を保証することで、初対面の相手とも安全に鍵を交換できる。
- Plan Mode
- 実装に着手する前に「何を・どの順で変更するか」の計画を提示させ、合意してから実装に進む使い方。
- PLL(位相同期回路)
- 出力信号の位相を基準信号の位相に同期させるよう帰還制御する回路(位相同期回路)。位相比較器・ループフィルタ・電圧制御発振器(VCO)・分周器から成り、この同期機構を応用して基準クロックを逓倍・分周し、CPUや周辺回路が必要とする動作クロックを生成する。低い基準周波数の発振子から高速な内部クロックを作れるため、消費電力とコストを抑えつつ必要な処理性能を実現する組込みクロック設計の要となる。
- Plug-in Registration Tool
- プラグインのステップ(メッセージ/テーブル/ステージ/Image)や webhook/Service Bus 等の送信先を登録するツール。
- PMBOK
- プロジェクトマネジメントの知識体系を整理したガイド(Project Management Body of Knowledge)。第6版まではスコープ・スケジュール・コスト・品質・リスク・調達・ステークホルダーなど10の知識エリアとプロセス群で整理されていた。第7版(2021年)以降は12の原理原則と8つのパフォーマンスドメインを中心とする構成へ移行している。
- PMF(Protected Management Frames)
- 無線LANの管理フレーム(認証解除(デオーセンティケーション)/切断(ディスアソシエーション)等)を暗号化・認証保護する仕組み。保護がないと第三者が偽の切断フレームを送りつけるDoS攻撃(認証解除攻撃)が容易になるため、WPA3では必須化されている。
- PMO(プロジェクトマネジメントオフィス)
- 複数プロジェクトの標準・手法・ツールを統括し、ガバナンスや資源配分の調整を行う組織単位。支援型・コントロール型・指揮型など関与度の異なる形態があり、組織内でのプロジェクトの一貫性・優先順位づけを担保する点で重要。
- policy assignment(ポリシーの割り当て)
- Teams のポリシーをユーザーやグループに適用する操作(グループ割当で自動展開)。定義済みの束である policy package とは別。
- Policy Intelligence
- 付与済みだが使われていない過剰権限を使用状況から発見し、最小化を推奨するツール群(IAM Recommender など)。最小権限の継続的な実現を支援する。
- policy packages(ポリシー パッケージ)
- 教育・医療など役割に合わせた複数の Teams ポリシーを定義済みの束としてまとめて適用する仕組み。ユーザー/グループへ適用する policy assignment とは別。
- PortFast
- PCなど末端ホストのみを接続するアクセスポートで、STPのリスニング/ラーニング状態を省略し即座にフォワーディング状態へ移行させるCisco機能。DHCPクライアントの起動待ちなどSTP収束待ちに起因する遅延を解消するが、スイッチ同士を接続するポートには設定してはならない(ループの危険)。
- Post Image(プラグイン)
- Dataverse プラグインの登録ステップに設定する、対象レコードの操作後(Create/Update 実行後)の列値のスナップショット。プラットフォームが自動生成する ID や計算列など、操作前には存在しなかった値をプラグインのロジックで参照したいときに使う。
- PostgreSQL
- オープンソースのオブジェクトリレーショナルデータベース管理システム(ORDBMS)。PostgreSQL Global Development Group が開発を主導し、PostgreSQL ライセンス(BSD/MIT に類似した寛容なライセンス)で配布される。OSS-DB Silver/Gold の対象製品。
- PostgreSQL のプロセス構成(postmaster/backend/background)
- PostgreSQL のプロセスアーキテクチャ。postmaster は最初に起動する親プロセスで接続受付とプロセス管理を担う。backend は各クライアント接続ごとに fork される子プロセス。background プロセス(autovacuum launcher、WAL writer、checkpointer 等)はサーバ全体で共有される補助処理を担う。
- PostgreSQL ライセンス
- PostgreSQL 本体に適用される寛容型(パーミッシブ)ライセンス。BSD/MIT 系に類似し、著作権表示と免責事項の保持を条件に、改変・再配布・商用利用を自由に認める。コピーレフト条項はない。
- postgresql.conf
- サーバ全体の動作パラメータを設定するメインの設定ファイル。listen_addresses(待受アドレス)・port(待受ポート)・max_connections(最大接続数)・logging_collector/log_destination(ログ出力方式)などを設定する。include ディレクティブで他ファイルを取り込める。
- POSシステム
- 販売時点情報管理(Point Of Sale)システム。レジでの商品販売と同時に商品コード・数量・売上時刻などを記録し、在庫管理や販売戦略の分析に活用する仕組み。
- Power Apps
- ローコードで業務アプリを作るツール(行動=act)。キャンバスアプリ(UI起点で自由設計)とモデル駆動型アプリ(Dataverse のデータ起点でレイアウト自動生成)がある。
- Power Apps Mobile
- iOS/Android で作成済みのキャンバス/モデル駆動型アプリを実行するモバイルアプリ。カメラや位置情報など端末機能も使える。
- Power Apps Studio
- キャンバスアプリを作成・編集するブラウザベースの開発環境。画面・コントロール・データソース・Power Fx 式を配置して作り込む。
- Power Apps コンポーネント フレームワーク(PCF)
- プロ開発者がコードで独自のコントロール(コードコンポーネント)を作り、キャンバス/モデル駆動型アプリに追加できる仕組み。フュージョン開発の代表例。
- Power Automate
- 定型作業を自動化するツール(自動化=automate)。フロー=トリガー+アクション。クラウドフロー(自動/インスタント/スケジュール)とデスクトップフロー(RPA・画面操作)がある。
- Power Automate for Desktop
- デスクトップフロー(RPA)を作成・実行する Windows 用アプリ。録画やアクションの組み立てで画面操作を自動化する。
- Power Automate Mobile
- スマホからフローの実行・承認応答・通知確認ができるモバイルアプリ。ボタンフローの起動にも使う。
- Power BI Desktop プロジェクト(.pbip)
- レポートとモデルをテキスト形式のファイル群として保存する形式。Git でソース管理しやすく、差分レビューや CI/CD に向く。
- Power BI アプリ
- ワークスペースのコンテンツを整理されたパッケージとして多数の閲覧者へ配布する仕組み。少数への個別共有やワークスペースロール(開発)と使い分ける。
- Power BI の構成要素(Power Query/モデル/ビジュアル)
- Power BI Desktop で Power Query を使い取り込み・整形(クレンジング)→データモデル(リレーションシップ・メジャー)を作成→ビジュアルでレポートを構築し、Power BI サービスで共有する。
- Power Fx
- Excel の数式に似た、Power Platform のローコード用の宣言的な数式言語。主にキャンバスアプリのロジックを式で記述する。学びやすさと再利用性が利点。
- Power Pages テンプレート
- よくある用途(イベント申込、問い合わせ、FAQ など)をあらかじめ用意したサイトのひな形。ゼロから作らず素早く公開できる。
- Power Platform Build Tools
- Azure DevOps/GitHub Actions でエクスポート/インポート/テストを自動化する CI/CD ツール。プラットフォーム内移送の Pipelines とは別。
- Power Platform CoE スターターキット
- 全社の Power Platform 利用を可視化・統制するための、Microsoft 提供のテンプレート集(CoE=センター オブ エクセレンス)。アプリ/フローの棚卸しやガバナンス自動化に使う。
- Power Platform Pipelines
- Power Platform 内で開発→テスト→本番へソリューションを自動移送する仕組み。Azure DevOps/GitHub の Build Tools(CI/CD)とは場所が異なる。
- Power Platform 管理センター
- 環境・容量・DLP ポリシー・分析・設定を一元管理する管理者向けポータル。各製品(Power Apps/Automate)の管理もここから行う。
- Power Query
- 各種ソースからデータを取得し、クレンジング・整形(列の削除・型変換・結合など)する Power BI のデータ準備エンジン。手順は再実行できる。
- PowerShell
- Windows由来のコマンドラインシェル兼スクリプト言語(現在はPowerShell 7でmacOS/Linuxにも対応するクロスプラットフォーム)。管理タスクの自動化に強力な反面、正規の管理ツールであるがゆえに侵入後の攻撃者にも悪用されやすく(Living off the Land)、実行ポリシーやログ記録による監視が重要となる。
- PPM(プロダクトポートフォリオマネジメント)
- 市場成長率と市場占有率の2軸で自社製品・事業を「花形」「金のなる木」「問題児」「負け犬」に分類し、経営資源の配分を検討する手法。
- Pre Image(プラグイン)
- Dataverse プラグインの登録ステップに設定する、対象レコードの操作前(Update/Delete 実行前)の列値のスナップショット。更新前の値と比較して変化を検出したり、削除前の情報を監査ログへ残したりする用途で使う。Create 操作には Pre Image は存在しない(変更前の状態が無いため)。
- Private Google Access
- 外部 IP を持たない VM から Google API(Cloud Storage など)へプライベートに到達できるようにする設定。外向き一般通信の Cloud NAT とは目的が異なる。
- Private Link と DNS 統合
- PaaS の公開 FQDN を CNAME で privatelink ゾーンに向け、プライベート DNS ゾーンの A レコードでプライベート IP に解決させる連携。忘れると公開 IP に解決して事故になる。
- Private NAT
- 内部 RFC1918 範囲を消費せずに、外向きやプライベート接続間の NAT アドレスを確保する仕組み。大規模環境での IP 枯渇やオーバーラップ回避に使う。
- Private Service Connect
- インターネットを経由せず、特定のマネージドサービスや公開サービスへプライベート IP で接続する仕組み。公開 IP の露出を避けたい接続に使う。
- PrivateLink エンドポイントサービス
- 自社サービスを NLB の背後に置き、PrivateLink 経由で他 VPC/アカウントへ非公開で提供する仕組み。トラフィックは AWS 内部のみを通り、インターネットや VPC ピアリングを介さずに SaaS 型提供ができる。
- Privileged Access Manager(PAM)
- 管理者の高権限を常時付与せず、承認付きで必要時のみ一時的に昇格し、自動失効させる仕組み。常時高権限(standing privilege)を避けて攻撃面を減らす。
- Proactive remediations
- Remediations(旧称 Proactive remediations、Endpoint Analytics の Scripts 配下で管理)という Intune の機能。検出スクリプトと修復スクリプトを1組にして、よくある問題(ディスク容量不足、特定サービス停止等)を自動検出・自動修復する。検出スクリプトの終了コードが非0(失敗)を返した場合に修復スクリプトが実行される仕組みで、スケジュール実行やデバイスグループ・RBACによる割り当て単位を指定できる。Endpoint Analytics の可視化と対になる「検出→是正」の実行系。
- Process advisor(プロセス アドバイザー)
- 自分の操作を記録(タスクマイニング)して所要時間や手順を分析し、自動化すべき作業を見つける Power Automate の機能。プロセスマイニングと対をなす。
- PSIと知的財産(IP)
- ネットワークで保護すべきデータの分類。試験ではPII(個人情報)・PHI(医療情報)・PSI・IP(知的財産)が挙げられる。PSIは機密性の高い情報を指す保護区分で、その頭字語の展開は教材により一定でない(個人のセキュリティ情報や決済関連情報などと説明される)。決済カード情報を扱う場合は、正式にはPCI DSSが規定する「カード会員データ(CHD=カード番号PAN・有効期限等)」の語で扱うのが正確。IP(知的財産)は特許・商標・企業秘密・独自技術情報など組織が権利を持つ無形資産。いずれも漏洩時の影響が大きく、分類・アクセス制御・暗号化の対象となる。
- psql
- PostgreSQL 標準の対話型ターミナル(コマンドラインクライアント)。SQL 文の実行に加え、バックスラッシュで始まるメタコマンドでカタログ情報の確認や表示設定の変更ができる。
- psql メタコマンド
- psql 内でバックスラッシュ(\)から始まる特殊コマンド。\l はデータベース一覧、\dt はテーブル一覧、\du はロール一覧、\c は接続先切替、\? はメタコマンドのヘルプ、\h は SQL 構文のヘルプ、\timing は実行時間表示のトグルを行う。
- PTP(Precision Time Protocol)
- IEEE 1588で規定される時刻同期プロトコル。NTPがソフトウェアベースでミリ秒オーダーの精度なのに対し、PTPはハードウェアタイムスタンプ支援によりマイクロ秒~ナノ秒オーダーの高精度な同期を実現でき、時刻ずれが業務に直結する高精度計測やモバイル無線バックホール等の用途で使われる。
- Pub/Sub
- イベントをリアルタイムに取り込み、複数のサービスへ配信するメッセージングサービス。ストリーミング取り込みに使う。
- Pull Request 要約
- 変更内容を自動で要約し、レビューの初速を上げる機能。人によるレビューを置き換えるものではない。
- Pull Request(PR)
- 作業ブランチ(compare)の変更をデフォルトブランチ(base)へ取り込む提案。レビューとチェックを経てマージする。
- Purview DSPM for AI
- Microsoft Purview のデータ セキュリティ態勢管理(AI 向け)。Copilot や AI アプリが扱う機微データのリスクと過剰露出を可視化し、ラベル付け・アクセス見直し・DLP による是正につなげる事前の態勢管理機能。
- Purview Information Protection
- Microsoft Purview Information Protection は、機微情報を発見・分類し、秘密度ラベルで保護(暗号化・アクセス制限・透かし)を適用する。Copilot の応答での露出を抑える基盤になる。
- Purview コンプライアンスポータルと監査
- Microsoft Purview の管理ポータルで、秘密度ラベル・DLP・保持・eDiscovery・監査ログを一元管理する。監査(標準/プレミアム)でユーザー/管理者の操作を追跡する。
- push / pull_request イベント
- コードの push や PR の作成・更新で起動する CI の中心イベント。branches/paths(および *-ignore)フィルターで対象を絞れる。
- pv 系コマンド(物理ボリューム操作)
- LVM で物理ボリューム(PV)を扱うコマンド群。pvcreate でディスクやパーティションを PV として初期化し、pvdisplay/pvs で確認する。
- PV(出来高計画値)
- ある時点までに完了しているべき作業に割り当てられた承認済み予算の累積値。EVMの基準線であり、実績のEV・ACと比較することでスケジュールとコストの差異(SV・CV)を算出する起点となる。
- PWM(パルス幅変調)
- 一定周期のパルス信号のオン時間(デューティ比)を変化させることで、擬似的にアナログ出力(電圧・電力)を制御する方式。モータの回転速度制御、LEDの明るさ調整、サーボモータの角度制御などに使われ、DA変換器なしでMCUのデジタル出力ピンから直接アナログ的な制御量を生成できる利点がある。
- pyATSとCisco Modeling Labs(CML)
- pyATS(Python Automated Test System)はネットワーク機器の状態確認やテストシナリオの実行をPythonで自動化するCisco製のテストフレームワーク。Cisco Modeling Labs(CML)はルータ・スイッチ等の仮想インスタンスでネットワークトポロジをシミュレーションできる環境で、実機なしで構成変更や自動化スクリプトを事前検証するのに使う。
- PySpark
- Python から Apache Spark を操作する API。DataFrame で大規模データを分散変換する。Fabric の主要な変換言語の 1 つ。
- Python requestsライブラリ
- PythonからHTTPリクエストを送るための代表的なサードパーティ製ライブラリ(標準ライブラリではなくpip installが必要)。requests.get(url, headers=, auth=, params=)のように呼び出し、返り値のresp.status_codeで結果を確認し、resp.json()でレスポンスボディをPythonの辞書/リストへ変換して扱う。POST/PUTやTLS検証のverify=等も指定でき、ネットワーク機器やコントローラのREST APIをスクリプトから呼ぶ定番の手段。
- p値
- 帰無仮説が正しいと仮定した場合に、観測されたデータと同等以上に極端な結果が出る確率。値が小さいほど帰無仮説を棄却する根拠が強く(統計的に有意)、A/B テストなどの仮説検定の判断基準として使われる。
- QC7つ道具
- パレート図・特性要因図・管理図・ヒストグラム・散布図・チェックシート・層別の7つの品質分析ツールの総称。数値データを主に扱い、原因分析から傾向把握まで目的に応じて使い分ける点が、状況に適した手法を選ぶ判断力として重要。
- QoS(優先制御・帯域制御)
- 限られた帯域を共有する複数トラフィックの通信品質を制御する仕組み。遅延・ジッタに敏感な音声/映像には優先制御(プライオリティキューイング)を、バーストするトラフィックにはシェーピング(超過分をバッファし送出を平滑化)やポリシング(超過分を破棄/マーキング)を適用する。DiffServ(DSCP)でクラス分けする。
- Query Store
- クエリのテキスト・実行プラン・実行時統計を履歴として保持する機能。性能退行(リグレッション)の検出やプラン強制の基盤になる。
- Queue ストレージ
- コンポーネント間を疎結合にするメッセージキュー。処理の山を平準化できる。
- Quiet Time policies
- 指定した時間帯(例:勤務時間外や夜間)にモバイルアプリの通知を抑制する Android/iOS 向けの Intune アプリ構成機能。ワークライフバランスや現場作業者の集中を確保する目的で、業務アプリからの通知だけを狙って一時的にミュートできる。
- RADIUS
- 認証・認可・アカウンティング(AAA)を集中管理するプロトコル。無線LANやVPN、IEEE802.1X環境で認証サーバとして用いられ、利用者ごとの認証情報を一元管理してネットワークアクセスを制御する。
- RAG の最適化
- RAG の品質は検索(retrieval)の質に依存する。類似度しきい値・チャンクサイズ・検索戦略(上位 k/再ランク付け)を調整し、ドメイン固有なら埋め込みモデルの選択・ファインチューニングで関連性を高める。セマンティック(ベクトル)検索とキーワード検索を組み合わせたハイブリッド検索で補完し、関連性メトリクスと A/B テストで定量的に評価・改善する。
- RAG の増分更新(差分再埋め込み)
- 知識ベースの更新時、全文書ではなく変更分だけを再チャンク・再埋め込みしてベクトルストアへ反映する手法。取り込みコストとレイテンシを抑え、鮮度を保つ。Knowledge Bases の同期は差分取り込みに対応する。
- RAG 検索機構(セマンティック/ハイブリッド)
- RAG で関連文書を取り出す仕組み。セマンティック検索=埋め込みの類似度で意味的に近いものを取得。ハイブリッド検索=キーワード(BM25 等)とベクトルを併用し再現率を高める。reranker で上位を並べ替え、必要分だけ文脈に渡す。
- RAG(検索拡張生成)
- 社内文書などを検索してプロンプトに添え、根拠ある回答を生成する手法。ハルシネーション低減に有効。
- RaMP(Rapid Modernization Plan)
- ゼロトラスト導入を、効果の高い成果(特権アクセス保護・ユーザーアクセス/パスワードレス・データ/アプリ保護)を短期で実現できる順に並べた優先度ガイダンス。「まず何から固めるか」を経営層に示す。参照アーキの MCRA とは別物。
- RASIS
- システムの信頼性を測る5つの指標の頭文字。Reliability(信頼性)・Availability(可用性)・Serviceability(保守性)・Integrity(保全性)・Security(安全性)から成る。
- RASP(Runtime Application Self-Protection)
- アプリケーション自身に組み込まれ、実行時のコンテキスト(呼び出し経路・入力・データフロー)を把握して攻撃をその場で検知・遮断する保護技術。外部通信を検査するWAFと異なり、アプリ内部から不正な挙動を判断できる。
- RAT(遠隔操作型マルウェア)
- 攻撃者が感染端末を遠隔から自由に操作できるバックドア機能を持つマルウェア。侵入後、他の内部端末への横展開(ラテラルムーブメント)や情報窃取・ランサムウェア展開の足場として悪用される。
- RDP Shortpath
- リバース接続(TCP リレー)の代わりに、クライアントとセッションホスト間で直接の UDP 経路を確立し、遅延とジッターを下げる Azure Virtual Desktop の機能。マネージドネットワーク向けとパブリックネットワーク向けがある。プライベート接続の Private Link とは目的が異なる。
- RDS Blue/Green デプロイ
- 本番(Blue)の複製(Green)を作り、エンジン更新やスキーマ変更を Green で検証してから、数十秒の切り替えで本番化するマネージド機能。リスクを抑えてメジャー更新やパッチを適用できる。
- RDS Performance Insights
- DB の負荷を「待機イベント」と「上位 SQL」で可視化し、ボトルネックを特定する性能監視機能。DB ロード(平均アクティブセッション数)をダッシュボードで追える。CloudWatch のメトリクスを補完する。
- RDS マルチ AZ とリードレプリカ
- マルチ AZ は同期スタンバイへ自動フェイルオーバーする高可用性(DR 目的)で、リードレプリカは非同期複製で読み取りをスケールする(性能目的)。役割が異なる。
- Re-run failed jobs / Re-run all jobs
- 失敗したジョブだけを個別に再実行する操作と、実行全体を再試行する操作。matrix の特定バリアントだけ落ちたときは前者、一時的(flaky)な失敗は後者が効率的。
- README
- プロジェクトの入口となる説明(概要・使い方・貢献方法など)。Markdown で書く。
- Real-Time Intelligence(リアルタイムインテリジェンス)
- ストリーミングデータの取り込み・格納・分析・アクションを担う Fabric のエクスペリエンス。Eventstream・Eventhouse・KQL・Data Activator を含む。
- Real-Time ハブ
- 組織内のストリーミング/イベントデータを一覧・発見し、接続できる中央の入口。Real-Time Intelligence の起点。
- rebase(リベース)
- 自分のコミットを対象ブランチの先端に並べ直し、履歴を直線化する方法。共有済みは注意。
- Redshift Serverless
- クラスター管理なしで使う Redshift。使用量(RPU)に応じて自動でスケールし、断続的・予測しにくい分析ワークロードのコストを最適化する。
- Redshift Spectrum
- Redshift から S3 上のデータを直接クエリする機能。ロード不要でデータレイクとウェアハウスを横断結合でき、Glue データカタログを参照する。
- Redshift の性能(RA3/WLM/分散キー)
- RA3=コンピュートとストレージを分離(マネージドストレージ)。コンカレンシースケーリング=同時実行ピークに一時的にクラスターを追加。ワークロード管理(WLM)=キューで優先度/メモリを制御。分散キー(DISTKEY)と並べ替えキー(SORTKEY)で結合とスキャンを最適化する。
- REINDEX
- 肥大化・破損したインデックスを作り直す SQL コマンド。通常の REINDEX は対象テーブル(または関係するインデックス)に排他ロックをかけてから再構築するため、実行中は該当テーブルへの読み書きがブロックされる。PostgreSQL 12 以降は REINDEX CONCURRENTLY オプションを使うことで排他ロックを避け、読み書きを許可したままオンラインでインデックスを再構築できる(ただし他のDDLは短時間ブロックされ、トランザクションブロック内では実行不可)。この排他ロックの有無はDBMS依存の仕様である。
- REINDEX CONCURRENTLY
- PostgreSQL 12 以降で使えるインデックス再構築コマンド。通常の REINDEX と異なりテーブルへの排他ロックを取らず、書き込みをブロックせずに無停止でインデックスを再構築できる。ただし途中で失敗すると INVALID 状態のインデックスが残ることがあり、その場合は手動で DROP して作り直す必要がある。
- Releases
- 特定バージョンを、タグに紐づけてリリースノートやアセットとともに公開する機能。
- Remote Help(Intune Suite)
- Intune Suite のアドオンで、ヘルプデスク担当者がエンドユーザーのデバイスへリモート接続し、画面表示または完全な操作制御で遠隔支援できる機能。Entra ID ベースの認証と RBAC でヘルプデスク側の権限を制御し、社外ネットワークからでも VPN 不要で接続できる。
- RemoteApp
- フルデスクトップではなく個別のアプリだけをシームレスなウィンドウで公開する Azure Virtual Desktop のアプリケーショングループ種別。デスクトップ全体を公開するデスクトップアプリグループと使い分ける。
- repository_dispatch
- 外部システムが API(POST)でカスタムイベント名を付けて起動するトリガー。外部連携に使う。
- Researcher(組み込みエージェント)
- Microsoft 365 Copilot の組み込みエージェントの一つ。社内データと Web を横断して深いリサーチを行い、複雑な調査タスクを段階的にまとめる。
- Resource Access Manager(RAM)
- 特定の AWS リソース(Transit Gateway、サブネット、ライセンスなど)をアカウントや組織をまたいで共有するサービス。リソースを複製せずに複数アカウントから利用できる。
- Resource Governor
- ワークロードを分類してリソースプール/ワークロードグループに割り当て、CPU・メモリ・I/O の上限を制御する機能(VM/MI 向け)。
- Responsible AI ダッシュボード
- モデルを責任ある AI の観点で評価する Azure ML のツール群。誤差分析・解釈可能性・公平性・反事実分析などを 1 つのダッシュボードで提供する。
- REST API(ネットワーク自動化)
- HTTPのメソッド(GET/POST/PUT/DELETE等)でリソースを操作する設計原則に基づくAPI。Catalyst Centerのようなコントローラへの問い合わせや設定変更をJSON形式のデータでやり取りでき、CLIへ1台ずつログインする代わりにスクリプトから多数の機器を一括操作できる。
- restart_after_crash
- バックエンドがクラッシュした際にサーバ全体を自動再起動するかを制御するパラメータ(既定 on)。off にすると異常終了時にサーバは停止したままとなり、原因調査が終わるまで自動復旧させたくない運用向け。
- restricted entities
- スパム大量送信などで送信を制限されたユーザーを確認し、原因に対処後に制限を解除する機能。サインイン制御の Conditional Access とは別。
- restricted Google access
- 到達できる Google API を許可したサービスのみに限定する仕組み(restricted.googleapis.com 経由)。VPC Service Controls と整合し、データ持ち出し経路を塞ぐ。Private Google Access と併用する。
- RFIとRFP
- システム調達の際、発注者がベンダーへ送る依頼文書。RFI(情報提供依頼書)は技術情報や実績を尋ね、RFP(提案依頼書)は要件を示して具体的な提案・見積りを依頼する。RFIのほうが先に行われることが多い。
- RIP
- ディスタンスベクタ型のIGP。メトリックにホップ数(経由ルータ数)を用い、ホップ数16を到達不能(無限大)とみなすため有効な最大ホップ数は15に制限される。設定が簡単だが収束が遅く大規模網に不向き。既定のアドミニストレーティブディスタンスは120。
- RISE with SAP
- SAP がマネージド(SaaS 型)で SAP S/4HANA 環境を運用する提供形態。顧客は統合と周辺サービスを担う。別サブスクリプションの SAP 環境と顧客 VNet をプライベート接続(VNet ピアリング/プライベートエンドポイント)で結ぶ。
- RLHF(人間のフィードバックによる強化学習)
- 人間の評価を報酬として大規模言語モデルを望ましい応答に調整する、強化学習に基づく手法。
- ROI(投資利益率)
- 投資によって得られた利益を投資額で割って算出する収益性の指標(ROI=利益÷投資額)。値が大きいほど投資効率が良いと判断できるが、投資回収に要する期間やキャッシュフローの時間価値は反映されないため、NPV・IRR・回収期間など他の指標と組み合わせて投資判断を行うことが望ましい。
- ROM
- 読み出し専用(Read Only Memory)の記憶装置で、電源を切っても記憶内容が消えない不揮発性メモリ。コンピュータの起動プログラムなど、書き換える必要のないデータの保存に使われる。電源を切ると内容が消える主記憶(RAM)と対比される。
- root guard
- スイッチポートで、本来ルートブリッジになるべきでない側から優位なBPDU(自分より小さいブリッジID)を受信した場合に、そのポートをroot-inconsistent状態にしてブロックするSTP機能。誤接続や不正な機器がルートブリッジの座を奪うトポロジ変化を未然に防ぐ。BPDU自体の受信でポートをerr-disableにするBPDU guardとは対処が異なる。
- ROSA(Red Hat OpenShift Service on AWS)
- AWS と Red Hat が共同提供するマネージド OpenShift(Kubernetes ディストリビューション)。OpenShift のエコシステム/開発者体験をそのまま AWS 上で使え、コントロールプレーン運用を任せられる。既存 OpenShift ワークロードの AWS 移行で選ぶ。
- Route 53 DNSSEC
- DNS 応答に署名し、改ざんやキャッシュポイズニングを検証で防ぐ仕組み。Route 53 ではゾーン署名と KMS の鍵で有効化する。
- Route 53 Resolver
- VPC のハイブリッド DNS 名前解決を担う仕組み。インバウンドエンドポイントはオンプレミスから VPC 内リソース(Amazon 提供 DNS)への問い合わせを受け付け、アウトバウンドエンドポイントは VPC からオンプレミスの DNS サーバーへ、条件付き転送ルールに従ってクエリを転送する。オンプレとクラウドで単一の名前空間を共有したいときに使う。
- Route 53 Resolver DNS Firewall
- VPC から発行される DNS クエリをドメインリストに照らして評価し、悪性/未許可ドメインへの名前解決をブロックするサービス。マルウェアの C2 通信や DNS トンネリングによるデータ持ち出しを検知・遮断する目的で使い、クエリログは DNS ログとして CloudWatch Logs や S3 に出力できる。
- Route 53 Resolver エンドポイント
- ハイブリッド DNS の仕組み。インバウンドエンドポイント=オンプレから AWS 内の名前解決を受ける入口。アウトバウンドエンドポイント+Resolver ルール=AWS から特定ドメインをオンプレ DNS へ転送する。VPC とオンプレで相互に名前解決できる。
- Route 53 ヘルスチェックとフェイルオーバー
- エンドポイントの正常性を監視し、異常時にフェイルオーバールーティングで正常な宛先へ自動的に切り替える。計算済みヘルスチェックや CloudWatch アラームとの連携も可能。
- Route 53 ホストゾーン(パブリック/プライベート)
- ドメインのレコードを保持するコンテナ。パブリックホストゾーンはインターネット向け、プライベートホストゾーンは VPC 内向け。同名ゾーンを両方持つスプリットビュー DNS も構成できる。
- Route 53 ルーティングポリシー
- DNS 応答の返し方を制御するポリシー群。フェイルオーバールーティング(ヘルスチェックで待機系へ)、レイテンシールーティング(最も近いリージョンへ)、加重ルーティング(割合配分)、位置情報ルーティングなどで可用性と性能を高める。
- RPA(ロボティック プロセス オートメーション)
- 人が画面で行う操作(クリック・入力・コピー)をソフトのロボットが模倣して自動化する技術。Power Automate ではデスクトップフローが該当。API のない業務に有効。
- RPCと同期・非同期
- RPC(Remote Procedure Call)はリモートの手続き(関数)を、あたかもローカルの関数呼び出しのように呼び出す設計方式で、リソース指向のRESTと対比される。同期呼び出しは応答が返るまで呼び出し元が待機する方式。非同期呼び出しは応答を待たずに処理を続け、結果は後でコールバックやポーリングで受け取る方式で、時間のかかる処理に向く。
- RPFチェック
- マルチキャストのループを防ぐための仕組み。ルータは受信したマルチキャストパケットについて、そのパケットの送信元アドレスへユニキャストで戻る経路として使うはずのインタフェースと、実際にそのパケットを受信したインタフェースが一致するかを確認し(Reverse Path Forwarding)、一致しなければ破棄する。
- rpm(RPM パッケージ直接操作)
- yum の下で働く低レベルツールで、照会機能が豊富。-qa 全一覧・-qi 詳細・-qR 依存・-ql パッケージ→ファイル・-qf ファイル→パッケージ・-V 改ざん検証・--checksig 署名確認。-p を付けると未インストールの rpm ファイルを調べる。依存解決はしない。
- RPO(目標復旧時点)
- 障害発生時に「どの時点のデータまで復旧できればよいか」を示す目標値。バックアップの頻度で決まり、値が小さいほど許容できるデータ損失が少ない。RTO(復旧までの時間)とは異なる指標。
- RPO(目標復旧時点)
- 障害発生時にどの時点のデータまで復旧できればよいかという目標値。RPOが短いほど許容できるデータ損失が少なく、より高頻度なバックアップやレプリケーションが必要になる。RTO(復旧までの時間)とセットでBCPの目標を定める。
- RSPANとERSPAN
- SPANを拡張し、ミラー対象のポートと監視ツールが同一スイッチ上にない場合に使う仕組み。RSPANは専用のVLANを経由してミラートラフィックを別のスイッチへ転送する(同一L2ドメイン内)。ERSPANはGREでカプセル化することでL3をまたいでミラートラフィックを転送でき、遠隔地の監視ツールへも届けられる。
- RSTPとRapid PVST+
- RSTP(IEEE 802.1w)は元のSTP(802.1D)の4状態(ブロッキング/リスニング/ラーニング/フォワーディング)をディスカーディング/ラーニング/フォワーディングの3状態に整理し、代替ポート(バックアップ経路)や提案/合意(proposal/agreement)機構により収束を大幅に高速化する。Rapid PVST+はRSTPをVLANごとに独立して動作させるCisco独自の実装で、VLANごとに異なるルートブリッジやロードバランシングを構成できる。
- rsyslog(システムログ)
- syslog 系の標準ログデーモン。rsyslog.conf のルールは「ファシリティ.プライオリティ アクション」形式で、プライオリティは指定した重大度以上が対象。@ホスト(UDP)/@@ホスト(TCP)で中央ログサーバーへ転送できる。手動でログを打つのは logger。
- RTO(目標復旧時間)
- 障害発生からサービスを復旧させるまでに許容される時間の目標値。値が小さいほど早期の復旧が求められる。RPO(許容できるデータ損失の範囲)とは異なる指標。
- RTO(目標復旧時間)
- 障害や災害の発生からどれだけの時間内に業務やシステムを復旧させるかという目標値。RPO(どこまでのデータ時点に戻すか)とは異なる軸で、BCPやDR計画のバックアップ方式・復旧手順を決める基準になる。
- Run Command
- SSH/RDP を開けずに多数のインスタンスへ一括でコマンドやスクリプトを実行する Systems Manager 機能。ターゲットをタグで指定し、結果を集約できる。
- runs-on
- ジョブを実行するランナーを選ぶキー。ubuntu-latest 等の GitHub ホスト型ラベルや、セルフホストのラベルを指定する。
- S/MIME
- 電子メールの本文・添付を公開鍵暗号とデジタル署名で保護する規格。暗号化により機密性を、署名により送信者の真正性と改ざん検知(完全性)を提供する。利用にはPKIによる証明書が必要となる。
- S3 Object Lambda
- S3 の GET リクエストと元のバケットの間に Lambda 関数を挟み、応答データをその場で加工して返す機能。個人情報のマスキング、画像のリサイズ、CSV から JSON への変換などをアプリ側のコード変更やデータの複製なしに実現できる。
- S3 Object Lock(オブジェクトロック)
- オブジェクトを WORM(書き込み一度・読み取り多数)で保護し、保持期間中の削除/上書きを禁止する。ガバナンスモード(特権で解除可)とコンプライアンスモード(誰も解除不可)、リーガルホールド(無期限保持)がある。法令対応・改ざん防止に使う。
- S3 Storage Lens
- 組織全体の S3 使用状況・アクティビティを可視化し、コスト最適化やデータ保護のための推奨を提示する分析機能。アカウント横断でストレージ傾向を把握できる。
- S3 アクセスポイント
- 1つのバケットにアプリ/チームごとの名前付きアクセス入口を複数作り、それぞれに専用のアクセスポリシーを付ける機能。巨大で複雑になりがちなバケットポリシーを分割して管理しやすくする。
- S3 アクセス制御(バケットポリシー/ACL/所有権)
- バケットポリシー=バケット単位のリソースポリシー(推奨の制御手段)。ACL=レガシーなオブジェクト/バケット権限(現在は無効化が推奨)。オブジェクト所有権の「バケット所有者強制」で ACL を無効化し、ポリシーに一本化する。パブリックアクセスブロックが最終防壁。
- S3 イベント通知
- オブジェクト作成/削除などのイベントを SNS・SQS・Lambda・EventBridge へ送り、処理を自動起動する仕組み。アップロードを契機にしたサムネイル生成やデータ取り込みパイプラインに使う。
- S3 サーバーアクセスログ
- バケットへのリクエストを詳細記録(リクエスタ・操作・応答)し、別バケットへ保存する機能。アクセス分析やセキュリティ監査に使う。API レベルの記録は CloudTrail データイベントが補完する。
- S3 ストレージクラス
- アクセス頻度とコストで選ぶ保存階層。Standard(高頻度)/Standard-IA・One Zone-IA(低頻度・取り出し料あり)/Intelligent-Tiering(自動最適化)/Glacier Instant・Flexible・Deep Archive(アーカイブ)。ライフサイクルで自動遷移する。One Zone は単一 AZ で安価だが冗長性が低い。
- S3 デフォルト暗号化
- バケットに新規保存するオブジェクトを自動的に暗号化する設定。現在は全てのS3バケットで既定で有効(SSE-S3)になっており、明示的に無効化することはできない。SSE-KMSやDSSE-KMSへ切り替えることで、より強い鍵管理やコンプライアンス要件に対応できる。
- S3 のバージョニングとレプリケーション
- バージョニングで上書き/削除から復元可能にし、クロスリージョン/同一リージョンレプリケーションで別ロケーションへ自動複製、MFA Delete で削除を保護する。
- S3 の暗号化と公開防止
- S3 のデータ保護。暗号化は SSE-S3(AWS 管理キー)、SSE-KMS(CMK で制御・CloudTrail で監査)、DSSE-KMS(二重暗号化)から選ぶ。誤公開はブロックパブリックアクセス(アカウント&バケット)+制限的なバケットポリシー+ACL 無効化で防ぐ。
- S3 の開発機能(署名付き URL・暗号化)
- 署名付き URL で一時的なアップロード/ダウンロード権限を発行し、マルチパートアップロードで大容量を分割並列化。暗号化は SSE-S3・SSE-KMS・SSE-C・クライアントサイドから選ぶ。
- S3 の性能機能(Transfer Acceleration / S3 Select)
- Transfer Acceleration はエッジ経由で遠距離アップロードを高速化、マルチパートアップロードは大容量を分割並列化する。S3 Select(オブジェクト内を SQL で部分取得)は新規利用が非推奨で、S3 上のクエリは Athena 等が推奨。
- S3 バケットキー
- SSE-KMSで暗号化する際、オブジェクトごとにKMSへ都度呼び出す代わりに、バケット単位の短命なデータキーを再利用してKMS呼び出し回数を大幅に削減する機能。KMSのAPIコストとリクエスト数によるスロットリングを抑えられ、大量のオブジェクトをSSE-KMSで扱う構成で有効化が推奨される。
- S3 バッチオペレーション
- 数十億規模のオブジェクトに対し、コピー・タグ付け・ACL 変更・Lambda 呼び出し・復元などの操作を一括実行するマネージドジョブ。対象は S3 インベントリやマニフェストで指定する。
- S3 ライフサイクル(遷移と有効期限)
- オブジェクトを経過日数で自動管理するルール。遷移=より安価なストレージクラスへ移す(例 30 日で Standard-IA、90 日で Glacier)。有効期限=古いオブジェクトや旧バージョン、未完了マルチパートを自動削除しコストを抑える。
- S3 レプリケーションの機能(RTC/バッチ/インベントリ)
- レプリケーション時間制御(RTC)=15 分以内のレプリケーションを SLA 付きで保証。バッチレプリケーション=既存オブジェクトを後から一括複製。S3 インベントリ=オブジェクトと暗号化/レプリケーション状態の一覧を定期出力し、棚卸しやバッチ操作の入力にする。
- S3 レプリケーションルール(CRR/SRR/双方向)
- CRR=クロスリージョン(DR・地理的近接)、SRR=同一リージョン(ログ集約・アカウント分離)。双方向レプリケーションでマルチリージョンの読み書きを支える。プレフィックス/タグで対象を絞り、所有者上書きや既存オブジェクトのバッチ複製も設定する。
- SaaS(Software as a Service)
- 完成したソフトをそのまま使うモデル。管理はほぼ事業者(例:Microsoft 365)。
- Safe Attachments
- Defender for Office 365 で添付ファイルをサンドボックスで実行(爆破)して未知のマルウェアを検出する保護。URL を保護する Safe Links とは別。
- Safe Links
- Defender for Office 365 で URL をクリック時に再評価して悪意あるリンクをブロックする保護(時間差の武器化にも有効)。添付を保護する Safe Attachments とは別。
- Sagaパターン(補償トランザクション)
- サービスごとにデータベースが分かれるマイクロサービスで、複数サービスにまたがる更新を一貫させるためのパターン。全体を1つのACIDトランザクションにせず、各サービスのローカルトランザクションを連鎖させ、途中で失敗したら実行済みの処理を打ち消す補償トランザクションを逆順に走らせて結果整合性を保つ。実装には中央のオーケストレータが各ステップを指示するオーケストレーション型と、各サービスがイベント連鎖で自律的に進むコレオグラフィ型の2方式がある。分散トランザクションの2相コミットを避けたい設計で採用される。
- SageMaker Autopilot
- 表形式データから前処理・アルゴリズム選択・チューニングを自動化し、説明可能な候補モデルを生成する AutoML 機能。
- SageMaker Clarify(バイアス/説明可能性)
- 学習データやモデルのバイアスを検出し、SHAP 値で予測への各特徴量の寄与を説明する機能。公平性と透明性の評価に使う。
- SageMaker Data Wrangler
- データの取り込み・分析・前処理・特徴量変換をGUI 中心で行うツール。300 以上の組み込み変換を適用し、処理をパイプライン化してエクスポートできる。
- SageMaker Debugger
- 学習中のテンソルやメトリクスを捕捉し、勾配消失・過学習・リソース未使用などの問題をルールで検知して訓練を最適化する。
- SageMaker Experiments
- 学習の試行(パラメーター・メトリクス・成果物)を記録・整理・比較し、再現性のある実験管理を行う機能。
- SageMaker Feature Store
- 特徴量を保存・共有・再利用するリポジトリ。低遅延推論向けのオンラインストアと学習向けのオフラインストア(S3)を持ち、学習と推論で同じ定義を共有して training-serving skew を防ぐ。
- SageMaker JumpStart
- 事前学習済みモデル(基盤モデル含む)やソリューションテンプレートをワンクリックで配置・微調整できるハブ。
- SageMaker Model Registry
- モデルをモデルパッケージグループでバージョン管理し、承認ステータス(承認/却下)を付けてデプロイの可否を統制するカタログ。
- SageMaker Neo
- 学習済みモデルを特定のエッジ/クラウドのハードウェア向けにコンパイル最適化し、推論を高速・軽量化する機能。
- SageMaker Pipelines
- データ処理→学習→評価→登録→デプロイの ML ライフサイクルを再現可能な DAG として自動化する CI/CD オーケストレーション。条件ステップで品質ゲートを設ける。
- SageMaker Processing ジョブ
- 前処理・後処理・モデル評価などをマネージドな計算上でスケールして実行するジョブ。コンテナで任意の処理を分散実行できる。
- SageMaker 学習ジョブと分散学習
- 組み込みアルゴリズムや独自コンテナでモデルを訓練するマネージドジョブ。データ並列/モデル並列の分散学習やマネージドスポットで大規模・低コストに学習する。
- SageMaker 学習の入力モードとデータ供給
- 大規模学習のデータ供給を選ぶ。File モード=学習前に全データを EBS にコピー(小規模・単純だが起動が遅い)、Pipe モード=S3 から直接ストリーミング(大容量・開始が速い)、Fast File モード=POSIX 風に遅延ロード(手軽さと速さの両立)。同じデータを多数ジョブ/HPO で再利用するなら FSx for Lustre(S3 連携の並列 FS)。組み込みは RecordIO-protobuf が効率的(疎データに有利)。
- SageMaker 推論方式
- 4方式を要件で選ぶ。リアルタイム=常時稼働・低遅延(Auto Scaling・多数モデルはマルチモデルエンドポイント)。サーバーレス=アイドル時ゼロにスケール(断続的・コールドスタート有)。非同期=大きいペイロード/長時間をキュー処理。バッチ変換=エンドポイント不要でデータセット全体をオフライン推論。
- SageMaker 組み込みアルゴリズムの選定
- 課題と出力の種類でアルゴリズムを選ぶ。表形式の分類/回帰は XGBoost(欠損・スケールに頑健な勾配ブースティング木)、線形/疎なら Linear Learner、推薦は Factorization Machines。クラスタリングは K-Means、次元削減は PCA、ストリーミング異常検知は Random Cut Forest。時系列予測は DeepAR(複数系列を 1 モデルで学習・確率的予測・コールドスタートに強い)、テキスト分類/埋め込みは BlazingText(Word2Vec)。コード不要の最適化は Autopilot(AutoML)。
- Salesforce コネクタ
- Salesforce CRM のデータに接続するコネクタ。外部 SaaS と連携する代表例。プレミアムコネクタ。
- SAML SSO(シングルサインオン)
- 組織/Enterprise のメンバーが IdP(Entra ID・Okta 等)で認証してから GitHub にアクセスする仕組み。認証を担い、退職者のアクセスを一括で止められる。アカウントの自動削除は SCIM の役割で、SAML 単独では行われない。
- Samsung Knox Mobile Enrollment
- Samsung 製 Android デバイスを Knox ポータルに登録し、初回起動時に Intune へ自動登録・構成する Samsung 独自の一括展開サービス。Google Zero Touch と役割は似るが、Samsung デバイス固有の Knox セキュリティ機能と連携できる点が異なる。
- SAP Central Services(SCS/ASCS)
- メッセージサーバーとエンキューサーバーを担う SAP の中核コンポーネント。単一障害点になりやすいため、Pacemaker クラスタリングで高可用性化する。
- SAP Deployment Automation Framework(SDAF)
- Terraform と Ansible で SAP システム全体(VM/OS/SAP・DB 構成)を再現可能に自動構築するフレームワーク。運用統合の Azure Center for SAP solutions とは役割が異なる(構築 vs 運用/管理)。
- SAP Landscape Management(LaMa)コネクタ for Azure
- SAP LaMa から Azure の VM/ストレージを操作(起動/停止・コピー/リフレッシュ等)するコネクタ。SAP 起点で Azure を制御する統合で、Azure 起点の Azure Center for SAP solutions とは方向が逆。
- SAP Quick Sizer
- SAP が提供する新規(グリーンフィールド)環境のサイジングツール。新規 SAP/HANA の所要リソースを見積もり、Azure 認定 VM 選定の入力にする。既存システムは SAPS 実測から見積もる。
- SAP 認定 VM
- SAP がサポート対象として認定した Azure VM の機種。SAPS/HANA メモリ要件に基づきサイジングして選ぶ。認定外の機種はサポートされないため、本番 SAP では認定リストと SAP Note で必ず確認する。
- SAPS(SAP サイジング指標)
- SAP Application Performance Standard。SAP システムの処理能力を表す単位で、既存システムの SAPS と HANA メモリ要件から Azure VM をサイジングする。新規構築は SAP Quick Sizer で見積もる。
- SARIF
- コード解析結果の交換フォーマット(Static Analysis Results Interchange Format)。サードパーティ SAST の SARIF を GitHub にアップロードすると Code Scanning アラートとして一元管理でき、CodeQL と共存できる。
- SASE(Secure Access Service Edge)
- ネットワーク機能(SD-WAN等)とセキュリティ機能(SWG・CASB・ゼロトラストネットワークアクセス等)をクラウド上で統合し、利用者やデバイスがどこからでも一貫したポリシーで安全にアクセスできるようにする概念。境界防御からクラウド前提の防御への移行を支える。
- Savings Plans の種別
- 1年/3年の利用コミットで割引を得る購入オプション。Compute Savings Plans=最も柔軟(EC2/Fargate/Lambda・リージョン/ファミリー横断)。EC2 Instance Savings Plans=特定ファミリー/リージョンに固定でより高割引。RI より柔軟なのが特徴。
- SBOM(ソフトウェア部品表)
- 含まれる依存とバージョンを標準形式(SPDX・CycloneDX)で列挙した「部品表」。依存関係グラフからエクスポートでき、規制対応やサプライチェーンの透明性に使う(脆弱性一覧そのものではない)。
- SCD(緩やかに変化するディメンション)
- ディメンション属性の変化の扱い。Type 1=上書き(履歴なし)、Type 2=行追加で履歴保持、Type 3=前の値を列で保持。
- schedule(cron)
- cron 式で定期実行するトリガー。cron は UTC 基準で、最短間隔の制約や混雑時の遅延があり、リポジトリが非アクティブだと停止する。
- Schema Conversion Tool(SCT)
- 異なる DB エンジン間の移行(例: Oracle→Aurora PostgreSQL)で、スキーマやストアドプロシージャを変換するツール。変換できない箇所はレポート化される。同種エンジンの移行では不要で DMS のみで足りる。
- SCIM(プロビジョニング)
- IdP でのユーザー作成・更新・削除を GitHub に同期し、アカウントを自動プロビジョニング/デプロビジョニングする仕組み。IdP で無効化したユーザーが GitHub からも自動削除され、退職時の取り残しを防ぐ。SAML(認証)とは役割が別。
- SCM(サプライチェーンマネジメント)
- 原材料の調達から生産・物流・販売までの一連の流れ(サプライチェーン)を企業間で情報共有し、全体最適化することで在庫削減やリードタイム短縮を図る経営手法。
- SCP 拒否リスト戦略
- 既定の FullAWSAccess を残したまま、禁止したい操作だけを Deny で列挙する SCP 運用方式。柔軟で最も一般的。SCP は権限の上限であり付与はしない(実効権限= SCP ∩ IAM)。
- SCP 許可リスト戦略
- 既定の FullAWSAccess を外し、許可する操作だけを明示的に列挙する SCP 運用方式。厳格だが、許可漏れで正当な操作も止まりやすく管理が重い。
- SCRAM-SHA-256
- pg_hba.conf で指定できるパスワード認証方式の一つ。チャレンジレスポンス方式でパスワードそのものを平文でもハッシュそのままでもネットワークに流さず、md5 方式より安全性が高い。PostgreSQL 10 以降のデフォルト推奨方式。
- SD-Access
- Ciscoのインテントベースネットワーキング製品群で、VXLANによるオーバーレイのファブリック(論理ネットワーク)を物理配線に依存しないアンダーレイの上に構築し、Catalyst Centerからポリシー(誰が・何に・どうアクセスできるか)を集中的に定義・自動配布するアーキテクチャ。手作業のCLI個別設定を減らし、セグメンテーションの一貫性と展開速度を高める。
- SD-WAN
- SDNの考え方をWANに適用し、複数の回線(専用線・インターネット回線等)をソフトウェアで一元管理し、アプリケーションの特性やポリシーに応じて最適な経路へ動的に振り分ける技術。拠点間WANの俊敏性とコスト効率を高める。
- SDN(Software-Defined Networking)
- 経路制御を担うコントロールプレーンと、パケット転送を担うデータプレーンを分離し、SDNコントローラがネットワーク全体を把握して経路制御を集中計算し、OpenFlow等で各スイッチに転送ルールを配信するアーキテクチャ。機器ごとの個別設定に頼らない集中制御・自動化を実現する。
- Search 関数(Power Fx)
- 入力した文字を含むレコードを部分一致で抽出する関数。検索ボックスでの絞り込みに使う。
- Secret Manager
- API キー・パスワード・証明書などのシークレットを安全に保管・取得・ローテーションするマネージドサービス。コードへの埋め込みを避ける。
- Secret Protection(シークレット保護)
- 旧 secret scanning。コミットされた/されようとする API キーやトークンなどの秘密を検出・ブロックする。リポ/組織で有効化。漏洩した秘密はファイル削除では履歴に残るため、トークンの無効化(ローテーション)が必須。
- Secret scanning
- コミット/プッシュ中の API キーやトークンを検出。push protection で漏洩を未然にブロック。
- Secrets Manager の自動ローテーション
- データベース等の資格情報を Lambda で定期的に自動更新し、漏えいリスクと運用負荷を下げる。RDS/Aurora は組み込みローテーションに対応する。
- secrets: inherit
- 再利用可能ワークフローの呼び出し側が、自分の持つすべてのシークレットをまとめて継承させる指定。
- Secure AI Framework(SAIF)
- 学習データの汚染・プロンプトインジェクション・モデルからの情報漏えいなど、AI 固有の脅威に体系的に備えるための Google の枠組み。
- Secure Web Proxy
- 外向き(egress)の通信を URL や SNI に基づいて許可リスト制御するプロキシ。一般インターネット外向きの Cloud NAT とは異なり、「どこへ出てよいか」をアプリケーション層で制御する。
- Secured Virtual Hub
- 仮想ハブに Azure Firewall を組み込み、Firewall Manager で複数ハブのポリシーを一元適用して通信を集中検査する構成。
- Security Command Center
- クラウド環境全体の設定ミス・脆弱性・脅威を一元的に可視化するセキュリティ態勢管理の中心。
- Security Health Analytics とカスタムモジュール
- Security Command Center の機能で、公開バケットや過剰なファイアウォール等の設定ミスを自動検出するクラウドセキュリティポスチャ管理(CSPM)。独自の検査はカスタムモジュールで追加する。予防はカスタム組織ポリシー。
- security manager(役割)
- セキュリティ方針の監督・アラート管理・例外承認を担う役割。コードの書き込み権限とは独立に、必要な人へ最小権限で付与できる。
- Security Overview
- 組織やリポジトリ全体のセキュリティ状態を一望できるダッシュボード。機能の有効状況・未対応アラート・リスク傾向を集約し、優先順位付けとカバレッジ確認に使う(修復そのものは行わない)。
- SECURITY.md
- リポジトリのセキュリティ報告手順(脆弱性の連絡先・対応方針)を公開するファイル。発見者がどこに報告すべきかを明確にする。
- SELECT 文(WHERE/ORDER BY/GROUP BY/HAVING/DISTINCT/LIMIT/OFFSET)
- 表からデータを取得する DML 文。WHERE で行を絞り込み、ORDER BY で並べ替え、GROUP BY でグループ化、HAVING でグループへの絞り込み、DISTINCT/SELECT DISTINCT で重複を除去し、LIMIT/OFFSET で取得件数と開始位置を制御する。
- self-help diagnostics / client health
- self-help diagnostics for Teams はよくある問題を自動でチェックしてガイドする自己診断。client health は Teams admin center でクライアントのバージョン/接続状態を確認する。詳細調査は client-side logs、軽い不具合は Teams client cache のクリア。
- Sensitive Data Protection(Cloud DLP)
- 保存データから個人情報などの機微データを自動で発見・分類し、マスキングできるサービス。
- Sentinel Graph
- Sentinel に集約された全社のデータをまたいで、エンティティ(ユーザー/デバイス/IP 等)間の関係をグラフとして分析する仕組み。単一テーブルの KQL では見えにくい横断的なつながりを明らかにする。
- Sentinel 分析ルールのタイプ
- スケジュール(柔軟な KQL を定期実行・大半の検知)、準リアルタイム(NRT・約1分間隔)、脅威インテリジェンス(取り込んだ IOC をログと照合)、機械学習(Fusion で多段階攻撃を相関)の4タイプ。平常からの逸脱を捉える異常(anomalies)も併用する。
- Service Quotas
- AWS サービスのクォータ(上限)を一元的に確認・引き上げ申請できるサービス。大規模設計でのスケール上限の管理に使う。
- Service Trust Portal
- Microsoft の監査レポート・認証・コンプライアンス文書を入手できるポータル(クラウド側の準拠を確認)。
- SES の配信可能性(バウンス/設定セット)
- メール到達率を保つ運用。バウンス(不達)・苦情(スパム報告)率が高いと送信が制限される。設定セットでイベント(送信/配信/バウンス/苦情)を SNS/CloudWatch に出し監視。DKIM/SPF/DMARC で認証し、専用 IP やウォームアップで評判を管理する。
- Session Manager
- ポートを開けず踏み台も不要で、ブラウザ/CLI からインスタンスのシェルに接続する機能。操作ログを CloudTrail/S3 に記録できる。
- Session Manager(ポートフォワーディング/監査)
- SSH/RDP やポートを開けずにシェル接続する SSM 機能の要点。ポートフォワーディングでローカルから RDS 等へ安全にトンネル。全セッションを CloudTrail/S3/CloudWatch に記録し監査可能。踏み台(Bastion)の代替になる。
- Set 関数(グローバル変数)
- アプリ全体で使えるグローバル変数に値を入れる関数。画面をまたいで保持する値の管理に使う。
- SET/SHOW
- SET は現在のセッションの実行時パラメータを変更し、SHOW はパラメータの現在値を表示する SQL コマンド。current_setting() 関数でも値を取得できる。
- Settings Catalog(Intune)
- Intune が公開する利用可能な全設定を検索・選択して自由に組み合わせ、独自の構成プロファイルを作成できる方式。あらかじめテンプレート化されたプロファイル種別と異なり、必要な設定だけをカタログから細かく選ぶため柔軟性が高く、新しい OS 設定も逐次追加される。
- setup-* アクション
- actions/setup-node などの公式アクションで、実行時に指定バージョンのツールを用意する。プリインストールに無い版を入れるときに使う。
- SFPとPoE
- SFP(Small Form-factor Pluggable)はスイッチやルーターの拡張スロットに挿す交換可能な光/銅トランシーバモジュール。PoE(Power over Ethernet)はデータと電力を同じイーサネットケーブルで同時に送る技術で、IP電話やアクセスポイント、監視カメラ等に別途電源工事なしで給電できる。
- SHA ピン留め
- サードパーティアクションを uses: owner/repo@<フルコミットSHA> で参照すること。タグは付け替え可能なため、改ざん防止には不変な SHA が最も安全。@main 等の流動的参照は避ける。
- SHA(コミットハッシュ)
- コミットの内容から計算される一意の識別子。コミットを一意に特定する。
- SharePoint Advanced Management と制限付きサイト アクセス
- SharePoint Advanced Management の制限付きサイト アクセスは、特定サイトへのアクセスを許可ユーザーのみに絞り、過剰共有による Copilot 経由の露出を抑える。
- SharePoint の過剰共有対策
- Copilot は既存権限を継承するため、広すぎる共有(過剰共有)があると機微データが Copilot を通じて露出しうる。データ アクセス ガバナンス レポートで広く共有された/機微ラベルのサイトを特定し、SharePoint Advanced Management の制限付きサイト アクセスで是正する。
- showmount(NFS エクスポート一覧)
- NFS サーバーが公開しているエクスポート一覧やマウント中のクライアントを確認するコマンド。`showmount -e サーバー名` で対象サーバーの公開ディレクトリ一覧を表示する。
- SIEM
- Security Information and Event Managementの略。各所(サーバー・ネットワーク機器・アプリ等)のログやイベントを一元収集し、相関分析して脅威を検知する仕組み。Microsoft Sentinel・Google SecOps・Splunk等の製品がこの役割を担う。
- SIEM(セキュリティ情報イベント管理)
- ファイアウォール・IDS/IPS・サーバー・エンドポイントなど複数の機器から出力されるログを一元的に収集・相関分析し、単体のログでは気付けない攻撃の兆候をアラートとして可視化する仕組み。SOCの監視業務の中核基盤となる。
- sign-in issues(サインインの問題)
- 認証・トークン取得・MFA・Conditional Access のポリシー評価など、アイデンティティ層に起因して Teams クライアントへサインインできない不具合。Entra ID のサインインログでブロック理由やポリシー名を確認して切り分ける。会議には参加できるが機能が使えないといった join meeting issues とは原因の層が異なる。
- SLA と複合 SLA
- サービスレベルアグリーメント(SLA)は稼働率の約束。複数サービスを直列に組み合わせると複合 SLA は各 SLA の積となり全体の可用性は下がる。冗長化で補う。
- SLA(サービスレベルアグリーメント)
- 保証された稼働率などを定める契約。達成できないとサービスクレジット(料金の一部返金)の対象になり得る。
- SLAACとNDP(IPv6)
- IPv6のアドレス自動設定。NDP(近隣探索プロトコル)はIPv4のARPやルータ探索を統合し、ルータが送るRA(ルータ広告)でプレフィックスを通知する。端末はRAのプレフィックスと自身のインタフェースIDを組み合わせてグローバルユニキャストアドレスを自動生成する(SLAAC=ステートレスアドレス自動設定)。DHCPv6サーバを要さない。
- SLAとSLM
- SLA(サービスレベル合意書)は、サービス提供者と利用者の間でサービス品質の水準(稼働率や応答時間など)を取り決めた合意文書。SLM(サービスレベル管理)は、SLAの内容を継続的に監視・見直しする活動。
- SLI(サービスレベル指標)
- SRE(Site Reliability Engineering)で信頼性を定量化するための実測指標。成功率・レイテンシ・可用性など、ユーザー体験に直結する値を継続的に測定する。SLOの目標値と対比させて達成度を評価する土台となる。
- SLO(サービスレベル目標)
- SLIに対して組織が設定する目標値(例:可用性99.9%)。契約上の約束であるSLA(サービスレベル合意)より内部的・保守的に設定されることが多く、SLOを下回りそうな兆候はエラーバジェットの消費で把握する。
- small files 問題
- 小さなファイルが大量にできると読み取りが遅くなる現象。OPTIMIZE による統合や適切なパーティション設計で対処する。
- SMART(Self-Monitoring, Analysis and Reporting Technology)
- HDD/SSD が自身の健康状態(温度・不良セクタ数など)を自己監視し、故障の予兆を報告する仕組み。smartd が常駐監視し、smartctl で状態確認や自己診断テストを実行する。
- SMTPプロトコル
- メールをサーバー間・クライアントからサーバーへ送信するためのプロトコル(TCP 25番等)。Postfix などの MTA がこのプロトコルでメールを配送する。
- SMTP認証(SASL)
- メール送信時にユーザー名とパスワードで送信者を認証する仕組み。SASL(Simple Authentication and Security Layer)の枠組みを使い、第三者による不正な中継(オープンリレー)を防ぐ。
- SNI(複数証明書)
- Server Name Indication。TLS ハンドシェイクでクライアントが接続先ホスト名を提示する拡張。これにより ALB(および NLB の TLS リスナー)でホスト名に応じて複数の ACM 証明書を出し分け、1 つのロードバランサーで多数のドメインを HTTPS 提供できる。
- SNMP
- ネットワーク機器を監視・管理するプロトコル。マネージャがエージェントへ定期的に問い合わせるポーリング(GET)に加え、エージェントが事象発生時に自発的に通知するトラップを持つ。管理情報はMIB(OIDで識別)で構造化される。SNMPv3は認証と暗号化を備え、平文のコミュニティ名に依存する v1/v2c の弱点を解消する。
- SNMPコミュニティ名
- SNMP v1/v2cにおいて、マネージャとエージェント間の認証に用いる平文の共有文字列。read-only(参照のみ)とread-write(設定変更可)の権限区分を持ち、正しいコミュニティ名を含まない要求はエージェントに拒否される。平文伝送のため盗聴・推測に弱く、機密性が必要な環境ではSNMPv3のユーザベース認証・暗号化への移行が推奨される。
- SNS ファンアウトとイベント駆動
- 1 つの SNS トピックから複数の SQS キューや Lambda へ同報配信するファンアウトで、疎結合な並列処理を実現する。EventBridge はルールでイベントを多数のターゲットへ振り分ける。
- SNS メッセージフィルタリング
- サブスクリプションにフィルタポリシーを設定し、メッセージ属性に一致するものだけを各サブスクライバーへ配信する仕組み。1 つのトピックから条件別に振り分け、不要な受信側処理を減らす。
- SOAR
- Security Orchestration, Automation and Responseの略。SIEMなどで検知されたアラート後の対応(調査・封じ込め・通知)をプレイブックで自動化・オーケストレーションする仕組み。アナリストの反復作業を減らし対応時間を短縮する。
- SOAR プレイブックとケース管理
- Google SecOps SOAR のプレイブックで安全・定型の対応(エンリッチ/隔離/チケット/通知)を自動化/オーケストレーションする。ケース管理ライフサイクルでは対応ステージの割り当て・エスカレーションのワークフロー・ハンドオフの有効性評価を行う。
- SOC 最適化(SOC optimization)
- Microsoft Sentinel が「使われていない取り込みのコスト」と「脅威に対する検知カバレッジの穴」を分析し、データやルールの最適化を推奨する機能。コスト効率と検知カバレッジを継続改善する。
- SoC(System on Chip)
- CPU・メモリ・グラフィックス・通信インタフェースなど、システムに必要な複数機能を1つの半導体チップ上に統合したもの。基板面積・配線遅延・消費電力を削減できる一方、機能変更には再設計(マスク改版)が必要になる。IoT機器やスマート家電で高機能・省スペースを両立する手段として選ばれる。
- SOC指標(検知・封じ込め・対応までの時間)
- SOCの有効性を測る代表的な指標群。Time to Detect(脅威発生から検知までの時間)、Time to Contain(検知から封じ込めまでの時間)、Time to Respond(検知から対応完了までの時間)等があり、これらを短縮することがSOC運用改善の主要な目標になる。
- SOLID原則
- オブジェクト指向設計で保守性と拡張性を高めるための五つの原則の頭字語。単一責任の原則(SRP=一つのクラスは一つの責務のみ)、開放閉鎖の原則(OCP=拡張に開き修正に閉じる)、リスコフの置換原則(LSP=派生型は基底型と置換可能)、インタフェース分離の原則(ISP=利用者に不要なメソッドを強制しない)、依存性逆転の原則(DIP=上位も下位も抽象に依存する)から成る。システムアーキテクトが変更に強いクラス構造を設計する際の指針となる。
- Sort・SortByColumns 関数
- レコードを指定の列で昇順/降順に並べ替える関数。一覧の表示順を制御する。
- sort/uniq
- sort は行を並べ替える(-n 数値・-r 逆順)。uniq は連続する重複行を除く(-c で件数)。uniq は隣接行しか見ないため、先に sort で並べるのが鉄則(sort | uniq -c)。wc は行数・語数・文字数を数える(-l 行数)。
- SoRとSoE(記録のシステム/エンゲージメントのシステム)
- SoR(システム・オブ・レコード)は基幹業務データを正確に記録・管理する安定性重視のシステムで、勘定系や在庫管理などが該当する。SoE(システム・オブ・エンゲージメント)は顧客や従業員との接点でスピーディーな価値提供を重視するシステムで、モバイルアプリやSNS連携などアジリティが求められる。ITストラテジストはDX推進の際、堅牢性が要のSoRを維持しつつ、変化への俊敏な対応が要のSoEを外側に構築する二層構造で全体最適化を図る。
- source(ドットコマンド)
- .(ドット)や source は、新しいプロセスを作らず現在のシェルでスクリプトを読み込む。設定ファイル(~/.bashrc 等)を再ログインせずに反映するのに使う。
- Spaces(Copilot)
- 関連するコード・ドキュメント・指示をまとめて文脈として束ねる場。Copilot に一貫した文脈を与える。
- Spanner
- 世界規模で強い整合性と高可用性を両立する分散リレーショナルデータベース。グローバルな基幹系に適する。
- Spark SQL
- Spark 上で SQL を使ってデータを変換・集計する方法。ノートブックから SQL に慣れた人でも大規模処理を書ける。
- Spark ノートブック
- PySpark や Spark SQL で大規模データを分散処理するノートブック。複雑な変換・機械学習・反復処理に向く。
- Spark パフォーマンス最適化
- Spark 処理を速くする工夫。スタータープール/カスタムプール、パーティション数、データのスキュー対策、キャッシュ、ブロードキャスト結合などを調整する。
- Spark 構造化ストリーミング
- Spark でストリーミングデータをバッチに似た記述で連続処理する方式。ノートブックで複雑なストリーム変換を書ける。
- Spark(Copilot)
- アイデアからアプリの雛形を素早く立ち上げる機能。
- Spatial Analysis
- Azure AI Vision の機能で、動画内の人の存在や移動を検出し、人数カウントや距離・入退室などの空間的なイベントを把握する。
- Speech-to-Text
- 音声を文字に変換する事前学習済みの API。コールセンターの文字起こしなどに使う。
- SPFアルゴリズム(ダイクストラ法)
- 重み付きグラフにおいて、始点から各ノードまでの最短経路を求めるアルゴリズム。リンクステート型ルーティングプロトコルが、収集したリンクステート情報からネットワーク全体のトポロジグラフを構築し、自ルータを根とする最短経路木を計算する際の基盤理論として用いられる。
- SPIバス(SPI通信)
- クロック・MOSI(マスタ→スレーブ)・MISO(スレーブ→マスタ)・チップセレクトの信号線で構成される同期式シリアル通信規格。全二重通信が可能でI2Cより高速だが、スレーブごとにチップセレクト線が必要なため接続台数が増えると配線数も増える。高速なセンサ/フラッシュメモリとの通信に向く。
- split-MACアーキテクチャ
- CAPWAPトンネル上で、802.11のMAC層機能をAPとWLCとで分担するアーキテクチャ。ビーコン送出やアクノリッジなどリアルタイム性の高い処理はAP側に残し、認証やローミング判断などの管理機能はWLC側に集約することで、多数のAPを一元制御しつつ無線特有の即応性を確保する。
- Spot Fleet
- 複数のインスタンスタイプ・AZ を横断してスポットインスタンス(一部オンデマンド併用可)の目標容量を維持する仕組み。割り当て戦略(容量最適化・最低価格など)で中断されにくい構成を自動選択し、中断時は代替プールへ自動的に再配置する。
- Spot VM
- 中断され得る代わりに大幅な割引が受けられる Compute Engine の VM。中断に強いバッチ処理などのコスト最適化に用いる。
- SQL
- リレーショナルDBを操作する言語。DDL(定義)/DML(操作)/DQL=SELECT(問い合わせ)/DCL(権限)に分かれる。
- SQL Managed Instance
- SQL Server と高い互換性を持つ PaaS。既存 SQL Server からの移行(リフト&シフト)に向く。
- SQL Server Agent ジョブ
- VM/Managed Instance のジョブスケジューラ。ジョブ・ステップ・スケジュール・オペレーター通知で定型保守を自動化する(Azure SQL Database には無い)。
- SQL Server on VM
- IaaS で SQL Server を動かす形態。OS まで自分で管理でき完全に制御できるが運用負荷は大きい。
- SQL Server コネクタ
- 既存の SQL Server(オンプレ/Azure)のテーブルに接続し、読み書きするコネクタ。オンプレ接続にはデータゲートウェイが要る場合がある。プレミアム。
- SQL データ分類
- 列に機密度ラベル・情報の種類を付与して機微データを識別・可視化し、監査と組み合わせて取り扱いを管理する戦略。
- SQL ログイン
- SQL Server/Azure SQL のサーバーレベルのセキュリティプリンシパル。認証(サーバーへ接続できるか)を担い、データベースへのアクセス権はユーザーへマッピングして初めて得られる。Microsoft Entra ログインと SQL 認証ログインの 2 系統がある。
- SQL 監査(サーバー/データベース)
- データベースイベントを記録し、Log Analytics・ストレージ・Event Hubs へ出力する。サーバー監査は全 DB に、データベース監査は個別に適用する。
- SQL 認証
- ユーザー名とパスワードを SQL 側で管理する従来型の認証。Entra 認証が使えない場合の代替で、強力なパスワードと最小権限が前提。
- SQL 分析エンドポイント
- レイクハウスのテーブルに対して自動生成される、読み取り専用の T-SQL クエリ用エンドポイント(書き込みは不可)。Warehouse のフル T-SQL とは区別する。
- SQLインジェクション
- Webアプリケーションの入力欄に不正なSQL文の断片を注入し、データベースを意図しない形で操作・閲覧させる攻撃手法。バインド機構(プレースホルダ)の利用や入力値の検証で防止する。
- SQLの結合(JOIN)
- 複数のテーブルを共通の列の値で結び付けて1つの結果として取得するSQL操作。両方に一致する行だけを返す内部結合(INNER JOIN)と、一方の全行を残す外部結合(OUTER JOIN)が代表的。
- SQS ショートポーリング
- SQS の受信方式のうち、メッセージが無くても即座に応答する既定方式。応答は速いが空受信が増え、リクエスト数とコストが増えやすい。
- SQS のリドライブ(DLQ からの再処理)
- デッドレターキューに溜まった失敗メッセージを、原因修正後に元のキューへ戻して再処理する機能(DLQ リドライブ)。最大受信回数(maxReceiveCount)を超えたメッセージが DLQ へ移る。毒メッセージの隔離と回復に使う。
- SQS ロングポーリング
- SQS の受信方式のうち、メッセージが来るまで最大 20 秒待ってから応答する方式。空受信が減りリクエストコストとノイズを削減でき、原則こちらが推奨。WaitTimeSeconds で設定。
- SRAM/DRAM
- SRAMはフリップフロップで1ビットを保持するため高速だがセルサイズが大きく高コスト・低密度、DRAMはコンデンサで電荷として保持するためリフレッシュ動作が必要だが小型・低コストで大容量化しやすい。組込みではキャッシュや高速ワークメモリにSRAM、大容量メインメモリにDRAMを使い分ける。
- SSE(Security Service Edge)/ Global Secure Access
- ユーザーとアプリの間にクラウドのセキュリティ層を挟む考え方。Microsoft の Global Secure Access 配下に Entra Internet Access(SWG)と Entra Private Access(ZTNA)がある。Conditional Access と統合してゼロトラスト化する。
- SSH
- ネットワーク越しに暗号化された通信でリモートのサーバーへ安全にログイン・操作するプロトコル(TCP 22番)。Linux のリモート管理の標準手段。
- SSH ポート転送
- 暗号化された SSH トンネルに他の通信を通す仕組み。ローカル転送 ssh -L 手元ポート:宛先ホスト:宛先ポート で、ファイアウォール越しの内部サーバー(DB 等)へ踏み台経由で安全に到達する。リモート転送は -R で逆向き。
- SSH 鍵の生成と管理(ssh-keygen/ssh-agent)
- ssh-keygen が鍵ペアを生成する(-t ed25519 が現行推奨。RSA/ECDSA/Ed25519)。パスフレーズで秘密鍵ファイル自体を暗号化できる。ssh-agent は復号済みの鍵をメモリに保持し、ssh-add で登録すればパスフレーズ入力はセッション1回で済む。
- SSH 鍵ファイル(authorized_keys/known_hosts/id_rsa)
- SSH 公開鍵認証で使う3種のファイル。秘密鍵 id_rsa と公開鍵 id_rsa.pub は接続元で作り、公開鍵を接続先の authorized_keys に登録する。接続元の known_hosts には接続先ホスト鍵の指紋(フィンガープリント)が記録され、鍵が変わると中間者攻撃の可能性として警告する。
- SSID
- 無線LANのアクセスポイントを識別する名前(Service Set Identifier)。クライアントは接続先のSSIDを選び、対応する認証・暗号化方式(WPA2/WPA3等)でアクセスポイントに接続する。ブロードキャストを止めても盗聴で判明しうるため、単独のセキュリティ対策にはならない。
- SSL-VPN
- HTTPS(TLS/SSL)を用いたリモートアクセスVPN。特にクライアントレス方式は専用VPNソフトの導入が不要でWebブラウザだけで利用でき、ゲートウェイが仲介する特定Webアプリのみにアクセスを限定しやすい。管理の及ばない私物端末・委託先PCからの限定アクセスに適する。
- SSL通信とpgcrypto
- PostgreSQL は SSL/TLS でクライアント-サーバ間通信を暗号化できる(postgresql.conf の ssl=on と証明書設定)。pgcrypto は保存データ自体をハッシュ化・暗号化する拡張機能(pgp_sym_encrypt() など)で、通信経路の暗号化とは別レイヤーの保護を提供する。
- SSM Automation(ランブック)
- ランブック(手順の定義)で運用タスクや自動修復を実行する機能。EventBridge や Config の検出と連携して是正を自動化する。
- SSM Document(ドキュメント)
- Systems Manager が実行する処理を定義した JSON/YAML 定義。Command 文書(Run Command 用)・Automation 文書(ランブック)・Session 文書などの種類があり、AWS 提供と自作がある。
- SSM Inventory
- 管理対象インスタンスにインストール済みのソフトウェア、アプリケーション、ネットワーク設定などのメタデータを収集し、一元的に可視化する Systems Manager の機能。収集データは Athena/QuickSight と連携してコンプライアンス評価や資産棚卸しに活用できる。
- SSM State Manager
- インスタンスの望ましい構成(OS 設定・エージェント・スケジュールタスクなど)を定義し、継続的かつ自動的に適用・是正する Systems Manager の機能。関連付け(association)としてスケジュール実行し、ドリフトが起きても定義した状態へ戻す。
- SSM 運用ツール(OpsCenter/Fleet Manager/Distributor)
- OpsCenter=運用上の問題(OpsItem)を集約し対処を追跡。Fleet Manager=サーバー群を GUI で管理(ファイル/レジストリ/プロセス)。Distributor=エージェント等のソフトウェアパッケージを配布・バージョン管理する。
- SSM 変更カレンダー / メンテナンス計画
- 自動化やパッチ適用を「許可/禁止」する期間をカレンダーで定義する機能。繁忙期や凍結期間(チェンジフリーズ)に変更を止め、Automation や Run Command の実行をゲートする。
- SSM(Source-Specific Multicast)
- 受信者があらかじめ「どのグループの、どの送信元からの」マルチキャストを受信したいかを明示的に指定する方式。RPを介した共有ツリーを使わず、受信者は直接その送信元への最短経路ツリーだけを構築するため、RPの単一障害点や不要なトラフィック受信を避けられる。受信者側の指定にはIGMPv3が必要。SSMはAWSの構成管理サービスSystems Manager(同じ「SSM」の略)とは別概念。
- SSO(Stateful Switchover)
- 冗長化されたスーパーバイザ(またはスタック/VSSのメンバー)を持つ機器で、アクティブ側の状態(コンフィグ・一部のプロトコル状態)をスタンバイ側へ常時同期させておき、アクティブ側に障害が起きても瞬時にスタンバイへ切り替えて通信を継続する高可用性の仕組み。シングルサインオン(SSO)とは別概念の同じ略語で、こちらはハードウェア冗長化の話。
- Star
- リポジトリのお気に入り登録。Stars 一覧に保存され、関心の指標になる(通知は来ない)。
- Start VM on Connect
- ユーザーが接続した時だけ、停止中のセッションホストを自動的に起動してアイドルコストを抑える Azure Virtual Desktop の機能。需要に応じて群全体を増減する自動スケールとは別物で、初回接続のオンデマンド起動が目的。
- Step Functions の状態(Map/Parallel/Choice)
- ステートマシンの構成要素。Task=処理、Choice=分岐、Parallel=並行分岐、Map=配列の各要素を反復(分散 Map で大規模並列)、Wait/Pass/Succeed/Fail。コールバック(.waitForTaskToken)で外部完了を待てる。
- Step Functions(Standard/Express・ASL)
- ワークフローを Amazon States Language(ASL)で定義する。Standard は長時間・厳密な実行履歴向け、Express は高頻度・短時間のイベント処理向けで課金とセマンティクスが異なる。
- STONITH / フェンシング(フェンスエージェント・SBD)
- STONITH はクラスタで障害ノードを確実に隔離(フェンシング)しスプリットブレインを防ぐ仕組み。Azure では API ベースの Azure フェンスエージェント、または共有ブロックデバイス方式の STONITH Block Device(SBD)で実装する。
- Storage Transfer Service
- 大量・継続的なデータを Cloud Storage へ転送するマネージドサービス。少量は gcloud/bq CLI が手軽。
- STP(セグメンテーション・ターゲティング・ポジショニング)
- 市場を属性やニーズで細分化する「セグメンテーション」、狙うセグメントを選ぶ「ターゲティング」、選んだセグメントの中で自社製品を競合と比べてどう位置付けるかを決める「ポジショニング」の3段階からなるマーケティング戦略立案プロセス。ストラテジストはSTPを経て初めて4Pや4Cといった具体的なマーケティング施策を設計できると位置付け、ポジショニングでは競合と異なる軸で優位性を主張できるかを重視する。
- STPのポート状態(ブロッキング/リスニング/ラーニング/フォワーディング)
- STPは収束するまでポートを段階的に遷移させ、ループを防ぎながらトポロジを安定させる。ブロッキング状態はBPDUのみ受信しフレーム転送もMAC学習も行わない状態、リスニング状態はBPDUを送受信してトポロジ計算を行うがまだ転送しない状態、ラーニング状態はMACアドレス学習を開始するが転送はまだしない状態、フォワーディング状態はユーザトラフィックの送受信とMAC学習の両方を行う最終状態である。
- STPのポート役割(ルートポート/指定ポート)
- STPは各スイッチ・各セグメントで転送に使うポートを役割によって決定する。ルートポートは非ルートブリッジがルートブリッジへ最短コストで到達する経路上の1ポート(各スイッチに1つのみ)であり、指定ポートは各セグメントでそのセグメントへのトラフィックを転送する役割を持つポート(セグメントごとに1つ)である。いずれにも選ばれなかったポートはブロッキング状態となり非指定ポートと呼ばれる。
- Strands Agents
- AI エージェントを少ないコードで構築するためのオープンソース SDK。モデル・ツール・プロンプトを結びつけて、推論しながらツールを呼ぶエージェントを作れる。
- strategy.matrix
- 1 つのジョブ定義を OS×バージョン等の複数バリエーションに自動展開する仕組み。include で追加、exclude で除外する。
- Sub-Agent(サブエージェント)
- 大きなタスクや膨らむ文脈に対し、サブタスクを委譲する下位エージェント。各エージェントのコンテキスト使用を最適化する。
- sudo/su(権限昇格)
- su は別ユーザー(su - で root)に成り代わる。sudo はコマンド単位で特権実行し実行記録が残るため、root 共有より安全。設定 /etc/sudoers は文法チェック付きの visudo で編集する(書き損じによるロックアウトを防ぐ)。
- Summary rules(Sentinel)
- 大量の生ログを事前に集約して小さな要約テーブルを作る Sentinel の仕組み。頻繁に使うクエリを高速・低コストに保つ。脅威を検知する分析ルールとは役割が異なる。
- SV(スケジュール差異)
- SV = EV − PV で算出するスケジュールの遅延・先行を示す指標。正の値は計画より進んでいる(先行)、負の値は遅れている(遅延)ことを意味し、符号を取り違えると是正措置の判断を誤る点に注意。
- SWOT分析
- 自社の強み(Strengths)・弱み(Weaknesses)という内部要因と、機会(Opportunities)・脅威(Threats)という外部環境要因を整理し、経営戦略の立案に役立てる分析手法。
- Synapse Spark / サーバーレス Spark
- ノートブックから大規模データを対話的に加工するための Spark コンピューティング。アタッチした Synapse Spark プールや AML のサーバーレス Spark を使う。
- Synapse の構成要素(SQL/Spark プール)
- Azure Synapse Analytics は専用 SQL プール(プロビジョンド DWH)、サーバーレス SQL プール(データレイクをクエリ)、Apache Spark プール(ビッグデータ処理)、パイプラインを 1 つのスタジオに統合する。
- synchronous_commit
- クライアントへコミット完了を返す前にどこまでWALの永続化を待つかを制御するパラメータ。on(既定)ではローカルディスクへのfsyncに加え、同期スタンバイ設定時はスタンバイ側でWALがフラッシュ(fsync)されるまで待機する(remote_write はスタンバイのOSへの書き込みまで、remote_apply は適用まで、と待機点が変わる)。off にすると性能は上がるがクラッシュ時に直近コミットが失われうる。
- systemd ジャーナル(journalctl)
- systemd が集めるバイナリ形式のログ。journalctl で問い合わせる(-u ユニット別・-b 今回起動・-f 追随・-p 重大度・--since 期間)。/var/log/journal/ が存在すれば永続化され、無ければメモリのみ(再起動で消える)。設定は journald.conf、古い分の削除は --vacuum-*。
- systemd ターゲット(デフォルトターゲット/シングルユーザーモード)
- 起動の到達点を表すユニットのグループ。multi-user.target(CUI・サーバー標準)/graphical.target(GUI)/rescue.target(シングルユーザーモード)。set-default は次回起動からの既定、isolate は今すぐの切り替え。
- systemd/systemctl
- 現代の Linux の初期化・サービス管理の仕組み。PID 1 として起動し、依存関係に基づきサービス(ユニット)を並列起動する(旧来の SysV init の後継)。systemctl はその操作コマンド(start/stop/enable/disable/status)。
- Systems Manager Incident Manager
- 重大インシデントの対応を統制するサービス。対応プラン・エスカレーション計画・オンコールスケジュール(ローテーション)・連絡先チャネルを管理し、発生時に自動でランブックを起動して関係者を招集、事後分析まで支援する。
- T-SQL(Fabric)
- ウェアハウスや SQL 分析エンドポイントで使う SQL 方言。セットベースの変換・集計に向き、Warehouse では読み書きとトランザクションも可能。
- Table ストレージ
- キー値(NoSQL)の単純で安価なテーブル。大量の軽量な構造化データに向く。
- Tabular Editor
- セマンティックモデルを効率的に編集する外部ツール。計算グループの作成やベストプラクティスアナライザーでの点検に使う。
- Tabular Workflows
- 表形式データ向けの AutoML パイプラインを、Vertex AI Pipelines 上のコンポーネントとして分解し、特徴量エンジニアリングやアーキテクチャ探索などの各段階を個別にカスタマイズ・再利用できるようにした機能。AutoML のブラックボックス的な自動化に対し、大規模データや特定段階への細かい制御が必要な上級ユースケース向け。
- TACACS+
- 機器管理(デバイスへのログインやコマンド実行の可否)向けのAAAを提供するCisco独自プロトコル。TCPを使い、パケット全体を暗号化し、認証・認可・アカウンティングを独立したプロセスとして扱える点で、UDPを使い認証と認可を1つのパケットにまとめ主にネットワークアクセス制御に使われるRADIUSと役割が異なる。
- TAPとSPAN
- いずれも監視ツールへトラフィックのコピーを渡す手段。TAP(Test Access Point)は専用のハードウェア機器を通信経路に物理的に挿入しリンク上の全信号をそのまま複製する。SPAN(Switched Port Analyzer、ポートミラーリング)はスイッチの機能で、指定したポートの通信を別のポートへソフトウェア的にコピーする。SPANはスイッチの負荷が高いとパケットを取り落とす場合があるが、TAPは専用機器のためほぼ取り落としがない。
- TCO Calculator
- オンプレミス環境と Azure への移行後を比較し、総保有コスト(TCO)の削減見込みを試算するツール。サーバー・ストレージ・ネットワーク・人件費(運用工数)などオンプレ側の項目を入力し、クラウド移行の投資対効果を示す提案資料に使う。
- TCO(総所有コスト)
- システムやサービスの導入から運用・保守・廃棄に至るまで、ライフサイクル全体で発生する費用の総額。初期投資(購入・構築費)だけでなく、運用・保守費、教育費、ライセンス更新費、将来的な移行・廃棄費用まで含めて評価する考え方で、初期費用の安さだけで調達案を選ぶと見落としが生じやすい投資判断の観点として重視される。
- TCP
- コネクション確立(3ウェイハンドシェイク)・順序保証・再送制御を行う信頼性重視のトランスポート層プロトコル。HTTP・SSH・データベース接続など、データの欠落や順序崩れが許されない通信で使われる。
- TCP/IP
- インターネットで標準的に使われる通信プロトコル群の総称。IPが宛先までデータを届ける経路制御を担い、TCPがデータの到達確認や再送制御を行い信頼性を確保する。
- TCP/IPモデル
- 通信機能をOSI参照モデルより簡略化した4階層(アプリケーション層・トランスポート層・インターネット層・ネットワークインタフェース層)で捉えるモデル。実際のインターネット技術(TCP/IP)はこのモデルに基づいて実装されており、現場ではOSIよりTCP/IPモデルが参照されることが多い。
- tcpdump
- コマンドラインでパケットを取得・表示するツール。GUIのWiresharkと異なりCLIで動作するため、GUIのないサーバーでの調査やスクリプトへの組み込みに向く。取得結果を.pcapファイルに保存してWiresharkで後から解析することもできる。
- Team(チーム)
- Organization 内でメンバーをまとめ、リポジトリ権限を付与する単位。入れ子にでき親の権限を継承。
- Teams for VDI
- 仮想デスクトップ(VDI)環境で Teams の音声/ビデオ メディアを最適化して使えるようにする構成。
- Teams Phone
- Microsoft Teams から PSTN(公衆電話網)へ発着信できるクラウド電話機能。通話プランや Operator Connect、ダイレクトルーティングで電話番号を割り当てる。
- Teams usage reports(利用状況レポート)
- Teams 管理センターで確認できる利用状況の集計レポート群。Teams利用状況、ユーザー活動、デバイス使用状況、アプリ使用状況、PSTN利用状況などを可視化する。通話/会議の音声品質の傾向を分析する CQD(Call Quality Dashboard)とは異なる観点(量・利用実態)のレポート。
- Teams メディア最適化(WebRTC Redirector)
- Azure Virtual Desktop で Microsoft Teams の音声/映像をローカル側で処理して品質を高める仕組み。Remote Desktop WebRTC Redirector Service を構成する。Teams を入れるだけでは最適化されない。
- Teams 管理センター
- Microsoft Teams のチーム・チャネル・ポリシーを管理する専用管理センター。会議・メッセージング・アプリの利用範囲をポリシーで制御する。
- TelnetとRDP
- 遠隔の機器を操作するためのプロトコル。Telnet(ポート23)は通信内容が暗号化されない旧式のリモートログイン方式で現在は非推奨、RDP(Remote Desktop Protocol・ポート3389)はWindowsのデスクトップ画面をグラフィカルに遠隔操作するプロトコル。
- tempdb の構成
- 一時オブジェクト・ソート・バージョンストアに使うシステム DB。複数データファイルや適切な配置で割り当て競合を抑え、性能を最適化する。
- Temporary Access Pass(TAP)
- 時間制限つきの一時的な資格情報。パスワードレスのオンボーディングや、認証方式を紛失したユーザーの再登録に使う。恒久的な認証方式ではない。
- Terraform(ネットワーク自動化)
- あるべきインフラの状態を宣言的な構成ファイルで定義し、実際の状態と比較した差分だけを適用するIaCツール。プロバイダというプラグインを介してクラウドだけでなくネットワーク機器・コントローラのリソースも管理対象にでき、適用結果はステートファイルで追跡される。
- Text-to-Speech API
- テキストを自然な音声に変換する Google Cloud の事前学習済み API。多言語・多数の音声に対応し、IVR や読み上げに使われる。
- TGW アタッチメント
- Transit Gateway に接続する個々の対象(VPC・VPN・Direct Connect ゲートウェイ・Direct Connect の Transit VIF・別 TGW との Peering)を表す単位。各アタッチメントはいずれか1つの TGW ルートテーブルに関連付けられ、その表を通じて他アタッチメントとの通信可否が決まる。
- threat analytics(Defender XDR)
- Microsoft のセキュリティリサーチが提供する脅威レポート。進行中キャンペーンや新しい攻撃手法について、影響を受けた資産・推奨対応・関連する検知/ハンティングクエリを示す。自組織が影響を受けているかを確認し能動的に探すのに使う。
- TLS
- 通信を暗号化し、証明書によってサーバー(要件次第ではクライアントも)を認証するプロトコル。ハンドシェイクで鍵交換と認証を行った後、対称鍵でデータを暗号化して送受信する。クラウドのロードバランサやCDNで終端し、証明書はマネージドサービスで発行・更新するのが一般的。
- TOAST
- ページサイズ(既定8KB)を超える大きな列値を自動的に圧縮・分割して別テーブル(TOASTテーブル)へ格納する仕組み(The Oversized-Attribute Storage Technique)。テキストや JSONB など可変長の大きな値を透過的に扱うために使われる。
- TOR(The Onion Router)
- 複数のノードを経由して通信を多重に暗号化しながら中継し、送信元を秘匿する匿名化ネットワーク。正当な検閲回避・プライバシー保護に使われる一方、送信元IPが追跡できなくなるためSOCにとってはデータ可視性を下げ、攻撃者やマルウェアの通信を隠す隠れ蓑にもなる。
- TOTP(時刻同期式ワンタイムパスワード)
- 共有シークレットと現在時刻を入力に、一定間隔(通常30秒)ごとに変化する使い捨てパスコードを生成する所持要素の認証方式。スマートフォンの認証アプリで広く使われ、パスワード(知識要素)と組み合わせて多要素認証を構成する。
- town hall(タウン ホール)
- 大規模な社内向け一方向配信イベント形式。全社集会やエグゼクティブからのアナウンスなど、視聴者の発言よりも発信者からの情報伝達を主目的とする。webinar より大きい規模(最大で数万人程度)に対応し、Q&A のみ限定的に有効化できる。
- TPM(セキュリティチップ)
- 暗号鍵の生成・保管や、起動構成の測定値をPCR(プラットフォーム構成レジスタ)に記録して完全性を検証する仕組み(メジャーメントブート)を担う、耐タンパ性を備えた専用ハードウェアチップ。鍵をソフトウェアから隔離して保護し、ディスク暗号化の鍵管理などに用いられる。
- Transactional Batch
- 同一論理パーティション内の複数項目をアトミック(全成功か全失敗)に処理する Cosmos DB SDK の機能。大量項目を並列に高スループットで投入する Bulk Support(非アトミック)とは目的が異なる。
- Transfer Appliance
- 大量データを物理デバイスに格納して輸送し、Cloud Storage へ取り込むオフライン転送サービス。ネットワーク転送が現実的でない規模に向く。
- Transit Gateway
- 多数の VPC とオンプレミスを単一のハブに集約して相互接続するルーター。VPC ピアリングのフルメッシュを避け、ハブ&スポークで大規模なネットワーク接続を簡素化する。
- Transit Gateway Connect
- SD-WAN アプライアンスや仮想ルーターを GRE トンネル+BGP で Transit Gateway に高スループット接続するアタッチメント種別。
- Transit Gateway vs VPC ピアリング
- 接続方式の選択。VPC ピアリングは 1 対 1・非推移的(A-B、B-C があっても A-C は通れない)でフルメッシュは管理が爆発する。Transit Gateway はハブ&スポークで多数の VPC/オンプレを集約し、ルートテーブルでセグメント制御する(大規模向け)。
- Transit Gateway アプライアンスモードと集中検査
- 多数の VPC のトラフィックを 1 か所で検査する構成(インスペクション VPC)では、TGW のルートテーブルを分割して検査 VPC を経由させる。往復で行きと戻りが別 AZ のアプライアンスを通ると非対称ルーティングで戻りが落ちるため、TGW のアプライアンスモードを有効化して同一フローを同じ AZ のアプライアンスに固定する。
- Transit Gateway ルートテーブル
- Transit Gateway に接続された各アタッチメント間の到達性を制御するルートテーブル。関連付け(アタッチメントをどのルートテーブルで経路解決するか)と伝播(他アタッチメントのルートを自動的に注入するか)を組み合わせ、本番/開発など環境間のセグメント分離を実現する。
- Translation API
- 多言語間の翻訳を行う事前学習済みの API。サイトの多言語化などに使う。
- TTL(Time to Live)
- Cosmos DB のコンテナに既定 TTL を設定すると、古い項目をトランザクションストアから自動削除できる(項目ごとに上書き可)。データ寿命の管理に使う。分析ストアの保持とは別。
- TTP
- 攻撃者の行動を戦術(Tactics・攻撃全体の目的)・技術(Techniques・目的を達成する一般的な方法)・手順(Procedures・具体的な実装や手口)の3段階で捉える分析用語。MITRE ATT&CKはこのTTPをカタログ化したもの。
- Twelve-Factor App(十二要素)
- クラウドネイティブなアプリ設計の原則集。設定は環境変数へ外出し、プロセスはステートレス、ログはイベントストリームとして扱う、廃棄容易性、開発/本番の一致など。スケールしやすく移植性の高いアプリの指針。
- UART(Universal Asynchronous Receiver/Transmitter)
- クロック信号を共有せず、送受信の各デバイスが独立したクロックとあらかじめ合意した通信速度(ボーレート)に基づいてデータを非同期にやり取りするシリアル通信方式。配線がTX/RXの2本のみと簡素な一方、双方のボーレート設定が一致していないと通信できない。デバッグ用コンソールや対1機器の単純な通信に広く使われる。
- UC(アンダーピニング契約)
- 外部の供給者やベンダと結ぶ契約で、SLAで顧客に約束したサービスレベルを外部委託部分から支えるもの。OLAが社内合意であるのに対し、UCは外部との法的契約という違いがある。サービスマネージャはSLA目標を満たせるようUCの目標値やペナルティを設計し、供給者の履行状況を監視して、外部依存がサービスレベルの弱点にならないよう管理する。
- UDM とパーサー
- UDM(Unified Data Model)は Google SecOps が取り込んだログを正規化する統一スキーマで、ソースに依存しない検索/検出を可能にする。パーサーは生ログからフィールドを抽出し UDM へ正規化する(必要に応じて変更/拡張)。
- UDP
- コネクションを確立せず、順序保証や再送を行わない軽量なトランスポート層プロトコル。オーバーヘッドが小さく高速なため、DNS 問い合わせや動画/音声ストリーミングなど、多少の欠落より低遅延を優先する通信に使われる。
- UEBA と脅威インテリジェンス
- UEBA(ユーザー/エンティティの行動分析)で平常からの逸脱を検知し、脅威インテリジェンス(IoC・MITRE ATT&CK)と突き合わせて高度な攻撃を特定する。
- UEFI/BIOS
- PC の電源投入直後に動くファームウェア。ハードウェアの初期化(POST=自己診断)とブートデバイスの選択・優先順位付けを行い、ブートローダーを読み込む。UEFI は BIOS の後継で GPT ディスクや大容量に対応する。
- ULAとAPIPA
- ULA(ユニークローカルアドレス)はIPv6でfc00::/7に定義され、実際に割り当てて使われるのはローカル生成のfd00::/8の範囲となる、インターネットにはルーティングされない組織内限定のアドレス(IPv4のプライベートアドレスに相当)。APIPAはDHCPサーバーが見つからない場合にWindows等が自動的に割り当てる169.254.0.0/16の範囲のIPv4アドレスで、同一セグメント内のみで通信できる。
- ulimit/TMOUT
- ulimit はシェルとその子プロセスのリソース上限(-n ファイル数・-u プロセス数・-c core サイズ)。TMOUT は無操作で自動ログアウトする秒数で、放置端末対策として profile に設定する。
- UML(統一モデリング言語)
- オブジェクト指向のシステム設計・分析結果を統一的な記法で図示するための標準化されたモデリング言語。静的な構造を表すクラス図、システムと利用者の相互作用を表すユースケース図、オブジェクト間のメッセージのやり取りを時系列で表すシーケンス図など、目的に応じた複数の図種を持つ。
- UNDO/REDOログによる回復
- 障害回復でログを使い分ける2つの操作。UNDO はコミットされていないトランザクションの変更を取り消し、REDO はコミット済みだがディスクへ未反映の変更を再適用する。チェックポイント以降のログを両方の観点で走査し整合状態に戻す。
- unified diff
- 2つのファイル(または同じファイルの変更前後)の差分を表す標準的なテキスト形式。変更前行を「-」、変更後行を「+」で示し、変更箇所の周辺行数を「@@」で始まるハンク見出しで示す。Gitのdiffやコードレビュー、設定変更のレビューで広く使われる。
- Universal Print
- オンプレのプリントサーバーを置かずに、クラウド経由でセッションホストから直接印刷できる Microsoft の印刷基盤。Azure Virtual Desktop の印刷要件をサーバーレスで満たす。
- unmanaged ソリューション
- 開発環境でコンポーネントを自由に追加・編集できる作業用のソリューション状態。コンポーネントはロックされておらず、他のソリューションのコンポーネントを直接編集することもできる。開発が完了したら managed に変換(エクスポート時に選択)してテスト/本番環境へ配布する。
- UpdateContext(コンテキスト変数)
- 1 つの画面内だけで使うコンテキスト変数に値を入れる関数。その画面限定の一時的な状態管理に使う。
- UpsertRequest
- レコードが存在すれば更新・なければ作成を 1 操作で行うメッセージ。先に Retrieve して分岐する手順を不要にする。CreateRequest/UpdateRequest と区別。
- upstream
- フォーク元(本家)を指す慣習的なリモート名。自分の fork は origin。
- USERELATIONSHIP(DAX)
- モデル内の非アクティブなリレーションシップを、特定の計算内でのみ一時的に有効化する DAX 関数。CALCULATE の修飾子として使い、テーブル間に複数の関係(例:注文日と出荷日)がある場合にどちらを使うかを式単位で切り替える。
- UUID/ラベル(blkid)
- ファイルシステムを識別する堅牢な方法。/etc/fstab で UUID= やラベルを使えば、/dev/sdb が /dev/sdc に変わるような接続順の変化に影響されない。blkid で UUID を確認する。
- UXとUI
- UI(ユーザーインタフェース)は利用者と製品・システムの接点となる画面や操作方法そのもの。UX(ユーザーエクスペリエンス)は製品・サービスを利用する過程全体で利用者が得る体験・満足感を指す、より広い概念。
- V-Order
- Parquet/Delta を読み取りに最適化して並べ替える Fabric の書き込み最適化。Power BI(特に Direct Lake)や SQL の読み取りが速くなる。
- VAC(完成時差異)
- VAC = BAC − EAC で算出する、完成時点での予算と見積りコストの差異。正の値は予算内で完了見込み、負の値は予算超過の見込みを示し、プロジェクト完了時の財務パフォーマンスを事前に予測する指標として重要。
- VACUUM
- タイムトラベルで不要になった古い未参照ファイルを削除し、ストレージを回収する Delta の保守コマンド。保持期間に注意。
- VACUUM FREEZE とトランザクションID周回
- トランザクションIDは32ビットの循環カウンタのため、対処せず放置すると周回(wraparound)し古いデータが将来のものとして不可視になりうる。VACUUM FREEZE は古い行を「常に可視(frozen)」とマークして周回対策とする標準手段(PostgreSQL 9.4 以降はXIDをFrozenXIDへ書き換えるのではなく、タプルヘッダのフローズンビットで実装)。放置すると自動でautovacuumが緊急モード実行し、それでも間に合わなければ新規書き込みを拒否する段階に至る。
- VACUUM/ANALYZE
- VACUUM は削除・更新で発生したデッドタプル(不要領域)を回収し、テーブルの肥大化を防ぐ。VACUUM FULL はテーブルを排他ロックして物理的に再構築し領域をOSへ返す(通常運用では推奨されない)。ANALYZE はクエリプランナが使う統計情報を更新する。両者は目的が異なり、autovacuum が定期的に自動実行する。
- vacuumdb
- シェルから VACUUM(および ANALYZE)を実行できるコマンドラインラッパー。-a で全データベース、-z で ANALYZE も同時実行、-j で並列実行数を指定するなど、cron 等でのメンテナンス自動化に使いやすい。
- Veo
- Google の動画生成モデル。テキストなどの指示から動画を生成する。
- Vertex AI
- 機械学習モデルの構築・学習・デプロイ・運用を一気通貫で行える統合 AI プラットフォーム。基盤モデルの利用も可能。
- Vertex AI Agent Builder
- 目的に向け自律的に行動するエージェントや検索アプリを構築するための Vertex AI の仕組み。
- Vertex AI AutoML
- コードをほぼ書かずに、表形式・テキスト・画像・動画データから高品質なカスタム ML モデルを自動構築する Vertex AI の機能。ニューラルアーキテクチャ探索とハイパーパラメータ調整を裏側で行い、精度と学習コストのバランスを取ったモデルを出力する。素早い SQL 分析だけなら BigQuery ML の方が手軽な場合もある。
- Vertex AI Experiments と TensorBoard
- 実験の再現性のための追跡。Vertex AI Experiments はパラメータ/メトリクス/成果物を記録・比較し、Vertex AI TensorBoard は学習曲線などを可視化する。役割が補完的で併用する。
- Vertex AI Feature Store
- 計算した特徴量を集約し、チームやモデル間で再利用する仕組み。訓練と推論で同じ特徴量を使い、重複計算と訓練/サービングスキューを防ぐ。推論時の低遅延取得はオンラインサービング、一括の訓練用はオフライン。
- Vertex AI Model Monitoring(スキュー/ドリフト)
- 本番モデルを継続的に評価し、訓練/サービングスキュー(訓練 vs サービングの入力分布の差)と特徴量/予測ドリフト(時間による変化)を検知してアラートする。しきい値超過で再訓練をトリガーする。ラベル遅延時はアトリビューション変化を代理指標にできる。
- Vertex AI Model Registry
- 学習済みモデルのバージョン・系統(リネージ)・評価指標・デプロイ状況を一元管理するリポジトリ。同じモデル名の下に複数バージョンをまとめて追跡でき、どのバージョンがどのエンドポイントにデプロイ中かを一目で把握できる。モデルガバナンスと再現性確保の起点となる。
- Vertex AI Pipelines(Kubeflow/TFX)
- Kubeflow Pipelines や TensorFlow Extended(TFX)で定義した ML パイプラインを、マネージドでサーバーレスに実行するサービス。汎用(ML 以外含む)ワークフローの依存/スケジュールは Airflow ベースの Cloud Composer を使う。
- Vertex AI Studio
- 本格運用の前にプロンプトを手軽に試作・比較・検証できる Vertex AI の機能。
- Vertex AI Workbench
- Google Cloud のマネージドな JupyterLab ベースの ML 開発環境。VPC Service Controls・限定公開 Google アクセス・最小権限のサービスアカウントなど、本格的なエンタープライズ ML 開発向けのセキュリティ制御を適用できる。BigQuery や Cloud Storage とのネイティブ連携が組み込まれている。
- Vertex AI の公開/限定公開エンドポイント
- オンライン推論のデプロイ先。インターネット公開は公開エンドポイント、VPC 内に閉じて低遅延/非公開にするなら限定公開エンドポイント(Private Service Connect)。需要追従は Vertex AI Prediction の自動スケールやコンテナ化サービングで行う。
- Vertex Explainable AI
- モデルの個々の予測に対し、どの特徴量がどれだけ寄与したか(特徴量アトリビューション)を数値化して示す Vertex AI の機能。表形式データにはサンプリング Shapley 等、画像データには統合勾配等の手法を使い分ける。規制対応の説明責任・デバッグ・バイアス検出に使う。
- Vertex ML Metadata とリネージ
- パイプラインが生成した成果物・実行・系統(リネージ)を記録する仕組み。「どのデータ・コード・パラメータからこのモデルが生まれたか」を辿れ、監査や原因特定を可能にする。モデル/データのバージョニングと連携させる。
- VertiPaq(列ストアエンジン)
- インポート/Direct Lake モデルを支える列指向のインメモリエンジン。列ごとに高圧縮し、集計を高速化する。
- vg 系コマンド(ボリュームグループ操作)
- LVM でボリュームグループ(VG)を扱うコマンド群。vgcreate で PV から VG を作成し、vgextend で PV を追加、vgreduce で PV を除外、vgremove で VG を削除、vgdisplay/vgs で確認する。
- vi(vim)
- ほぼ全ての Linux にある標準エディタ。起動直後はノーマルモード(キーがコマンド)で、i/a/o で挿入モード(文字入力)へ、ESC で戻る。移動 hjkl、行削除 dd・コピー yy・貼り付け p(ヤンクバッファ経由)、検索 /・?。保存終了 ZZ/:wq、破棄終了 :q!、読み直し :e!。
- virsh
- libvirt を通じて仮想マシンを操作する CLI。virsh start/virsh shutdown で VM を起動・停止する。
- Visibility Map
- 各ヒープページについて、そのページの全行がすべてのトランザクションから可視(かつ凍結済み)かどうかを記録するビットマップ。インデックス自体には行の可視性情報が無いため、Index Only Scan はこのマップを参照し、全行可視なページはヒープを読まずに済ませ、そうでないページのみヒープへフォールバックして可視性を確認する。VACUUM で更新される。
- Vision API
- 画像の分類や物体・文字の認識を、専門知識なしで利用できる事前学習済みの API。
- Viva Engage(旧 Yammer)
- 組織全体のコミュニティとつながりを促す社内 SNS 型のアプリ。Microsoft Viva スイートの一部で、リーダーとのつながりや知識共有に使う。
- VLAN アタッチメント
- Cloud Interconnect と VPC(Cloud Router)を結ぶ論理接続。物理接続(Interconnect)を作った後、VLAN アタッチメントで実際の VPC へトラフィックを通す。
- VLAN(仮想LAN)
- 物理的な配線を変えずに、スイッチのポートを論理的な複数のブロードキャストドメインに分割する技術。IEEE802.1QのタグVLANはフレームにVLAN IDのタグを付与し、1本のトランクリンクで複数VLANを区別して伝送する。異なるVLAN間の通信にはL3スイッチやルータによるVLAN間ルーティングが必要。
- VLAN間ルーティング
- 異なるVLAN(=異なるブロードキャストドメイン)間で通信するにはレイヤ3の経路制御が必要であり、これをVLAN間ルーティングと呼ぶ。代表的な実装は、1本のトランクリンク上でVLANごとにサブインタフェースを設定するルータオンアスティックと、スイッチ自体がVLANごとのSVI(仮想インタフェース)を持ちルーティングを行うL3スイッチの2方式である。
- VLSM(可変長サブネットマスク)
- 1つのアドレス空間を、部門やセグメントごとに必要なホスト数に応じて異なる長さのサブネットマスクで分割する手法。各セグメントに過不足のないサイズを割り当てることでアドレスの無駄を抑え、攻撃対象領域の不要な拡大も避けられる。
- VM 拡張機能とカスタムスクリプト
- VM へ構成や自動化を後付けする仕組み。カスタムスクリプト拡張で起動時にスクリプトを実行し、DSC や Azure Monitor エージェントもエクステンションで導入する。
- VMware Cloud on AWS
- オンプレミスの VMware vSphere 環境を AWS 上でそのまま実行できるサービス。既存の VMware ワークロードを再構築せずにクラウドへ移行/拡張する。
- VNet ピアリング
- 2 つの VNet を Microsoft バックボーンで低遅延に接続する。既定では非推移(A-B-C で A↔C は不可)なので、ハブ経由には UDR やゲートウェイトランジットが要る。
- VNF(仮想化ネットワーク機能)
- ルータ・ファイアウォール・ロードバランサ等の専用ハードウェアが担っていたネットワーク機能を、汎用サーバ上の仮想マシンやコンテナ上のソフトウェアとして実装したもの。NFV基盤(NFVI)上で稼働し、迅速な導入・スケール・機器更改の柔軟性を実現する。
- VPC Service Controls
- BigQuery や Cloud Storage などのマネージドサービスへのデータ持ち出しを、サービス境界(perimeter)で防ぐ仕組み。IAM の許可とは別レイヤーの統制。
- VPC エンドポイント
- VPC を AWS サービスへプライベート接続する入口。ENI を作るインターフェイスエンドポイント(PrivateLink 経由・多くのサービス)と、S3/DynamoDB 専用のゲートウェイエンドポイント(ルートテーブル経由・無料)がある。
- VPC エンドポイントの実装(プライベート DNS / エンドポイントポリシー)
- インターフェースエンドポイントでプライベート DNS を有効化すると、サービスの通常名が ENI のプライベート IP に解決され、コード変更なしでプライベート経路に切り替わる。エンドポイントポリシー(リソースベース IAM)でそのエンドポイント経由で許す API/リソースを限定し、S3 バケットポリシーの aws:sourceVpce 条件と組み合わせて特定エンドポイント経由のみに絞れる。ゲートウェイ VPC エンドポイントは S3/DynamoDB 専用で無料・ルートテーブル経由。
- VPC エンドポイントの種類とプライベート DNS
- ゲートウェイ型(S3/DynamoDB のみ・ルートテーブル経由・無料)とインターフェイス型(PrivateLink・ENI+プライベート IP・多数のサービス・時間課金)。プライベート DNS を有効にすると、公開サービス名のままエンドポイント経由で解決される。
- VPC ネイティブ クラスタとエイリアス IP
- GKE のネットワーク方式。エイリアス IP のセカンダリ範囲を Pod と Service に割り当てる。スケール上限は割り当てた IP 空間で決まるため、設計時に範囲を十分に確保する。
- VPC ネットワークピアリング
- 2 つの VPC ネットワークを直接接続して相互に通信できるようにする仕組み。
- VPC ピアリング
- 2 つの VPC を 1 対 1 で直接接続する仕組み。推移的ルーティングは不可で、多数の VPC を結ぶとフルメッシュになり管理が複雑化するため、大規模では Transit Gateway を使う。
- VPC フローログのフィールドと宛先
- フローログは送信元/宛先 IP・ポート・プロトコル・バイト数・ACCEPT/REJECT などを記録する。宛先は CloudWatch Logs・S3・Data Firehose。ENI/サブネット/VPC 単位で有効化し、拒否された通信の調査やトラフィック分析に使う。
- VPC 共有(VPC sharing)
- AWS Resource Access Manager(RAM)を使い、1つの VPC のサブネットを組織内の複数アカウントへ共有する仕組み。参加者アカウントはそのサブネット内にリソースを作成でき、ネットワーク管理を中央(オーナーアカウント)に集約しつつアカウント分離は維持できる。
- VPC(Virtual Private Cloud)
- Google Cloud のソフトウェア定義ネットワーク。グローバルなリソースで、リージョンをまたぐサブネットを 1 つのネットワークに収容する。ルート・ファイアウォール・ピアリングで通信を制御する。
- VPC/サブネットのクォータ
- 1リージョンあたりのVPC数、1VPCあたりのサブネット数など、VPCネットワーク設計に関わる上限値。これらはService Quotasで確認・引き上げ申請できる。一方、サブネットのCIDRサイズ(/16〜/28)はVPC/サブネットの仕様上の制約であり、Service Quotasの引き上げ対象ではない。サブネット自体のCIDR範囲は作成後に変更できないが、VPCにはセカンダリCIDRブロックを追加してアドレス空間を拡張できる。
- VPN Gateway
- インターネット経由の暗号化トンネルでオンプレミスと接続するサービス。
- VPN ゲートウェイ SKU と冗長性
- VPN ゲートウェイの性能/帯域/トンネル数を決める SKU。可用性のためにアクティブ/アクティブ構成やゾーン冗長を選ぶ。
- VPN(仮想プライベートネットワーク)
- 公衆ネットワーク上に暗号化された仮想的な専用回線を構築し、拠点間や在宅勤務者と社内ネットワークを安全に接続する技術。トンネリングと暗号化により通信内容の盗聴・改ざんを防ぐ。
- VRF(Virtual Routing and Forwarding)
- 1台のルータ/スイッチの中に、互いに独立した複数の仮想的なルーティングテーブルとFIBを持たせる仮想化技術。VRFが異なれば同じIPアドレス帯を重複して使っても経路が混ざらず、マルチテナントやサービスごとの経路分離に使われる。VRF間で通信させるにはルートリーキングや外部の接続点が必要になる。
- VRIO分析
- 自社の経営資源が持続的な競争優位の源泉となり得るかを、経済価値(Value)・希少性(Rarity)・模倣困難性(Imitability)・組織(Organization)の4つの問いで診断するフレームワーク。バリューチェーンやコアコンピタンス分析で洗い出した資源・能力について、この4条件をすべて満たす資源だけが持続的競争優位をもたらすと判断し、投資すべき資源を絞り込むために用いる。組織(O)が欠けると、価値・希少性・模倣困難性を満たしていても優位を活かしきれない点に注意する。
- VRRP(ゲートウェイ冗長)
- 複数の物理ルータを1台の仮想ルータとしてまとめ、共通の仮想IPアドレス・仮想MACアドレスを共有するプロトコル。端末のデフォルトゲートウェイに仮想IPを設定しておけば、マスタルータ障害時にバックアップが自動昇格して仮想IP/MACを引き継ぐため、端末設定を変えずにゲートウェイの単一障害点を解消できる。同種にHSRPがある。
- VRとAR(仮想現実・拡張現実)
- VR(仮想現実)はコンピュータが作り出した仮想空間に利用者を没入させ、現実の代わりとなる体験を与える技術。AR(拡張現実)は現実の風景や映像にコンピュータの情報を重ね合わせて表示する技術で、現実を置き換えるVRと現実に情報を付加するARという違いがある。
- VXLAN
- L2フレームをUDP/IPでカプセル化しL3網上にオーバーレイするトンネル技術。セグメント識別子VNIが24ビットのため約1677万のセグメントを識別でき、IEEE802.1QのVLAN ID(12ビット・最大4094)の上限を打破する。VTEPがカプセル化・非カプセル化を担い、大規模マルチテナントのデータセンターで用いられる。
- WAF Bot Control
- 既知の善玉ボット(検索エンジンクローラー等)と悪玉ボット(スクレイパー・クレデンシャルスタッフィング等)を識別・制御する AWS Managed Rules のマネージドルールグループ。導入初期はカウントモードでブロック前に影響を評価するのが推奨される。
- WAF のルール(マネージド/レート制限)
- AWS WAF は Web ACL にルールを並べて評価する。AWS マネージドルールグループ(共通脅威・OWASP・ボット)、レートベースルール(しきい値超過の IP を制限)、カスタムルールを組み合わせる。
- WAF ポリシーと検出/防止モード
- Web Application Firewall の構成。Application Gateway や Front Door に関連付け、検出モード(記録のみ)か防止モード(ブロック)を選ぶ。OWASP ルールセットで一般的な攻撃を防ぐ。
- WAF ロギング
- WAF が検査したリクエストの詳細(マッチしたルール・アクション・ヘッダー等)を CloudWatch Logs、S3、Kinesis Data Firehose のいずれかへ出力する機能。誤検知(false positive)の調査やルールチューニングに使う。
- WAF(Webアプリケーションファイアウォール)
- HTTP/HTTPS通信の中身を検査し、SQLインジェクションやクロスサイトスクリプティング(XSS)など、Webアプリケーション層を狙う攻撃を検知・遮断する防御装置・サービス。通信の宛先ポートやIPで制御する通常のファイアウォールと異なり、アプリケーションのリクエスト内容(パラメータ等)まで見て判断する。
- WAL アーカイブ(archive_command)
- WAL セグメントファイルが不要になる前に別の保管場所へコピーして保持する仕組み。postgresql.conf の archive_command で、各 WAL セグメントを退避する際に実行するシェルコマンドを指定する。
- wal_level
- WALへ書き込む情報量を制御するパラメータ。minimal はWALを最小限に抑え、レプリケーションもWALアーカイブ(PITR/ホットスタンバイ)もサポートしない、replica(既定・旧 archive/hot_standby を統合)はストリーミングレプリケーションとアーカイブに必要な情報を含む、logical はさらにロジカルレプリケーションに必要な追加情報(変更前の行データ等)を含む。
- WAL・チェックポイント関連パラメータ(fsync/checkpoint_timeout/max_wal_size/wal_keep_size/checkpoint_completion_target)
- WAL・チェックポイント関連の性能パラメータ。fsync はディスクへの実書き込み保証の有無(offはクラッシュ時のデータ損失リスク)。checkpoint_timeout は自動チェックポイントの最大間隔。max_wal_size はチェックポイント間に許容するWAL増加量の目安上限。wal_keep_size はスタンバイのために保持しておくWALの最小量。checkpoint_completion_target はチェックポイントの書き込みをどれだけの期間に分散させるかの目標割合。
- WAL(トランザクションログ)
- データファイルへの変更を実際に書き込む前に、その変更内容を先行して記録するログ。クラッシュリカバリの基盤であり、WAL アーカイブと組み合わせて PITR を実現する。
- walreceiver
- スタンバイ側でストリーミングレプリケーションの受信を担うプロセス。プライマリの walsender と接続し、受信した WAL をローカルの WAL へ書き込んで適用ワーカーに反映させる。接続が切れると設定に応じて自動的に再接続を試みる。
- walsender
- プライマリ側でストリーミングレプリケーションの送信を担うバックエンドプロセス。接続してきた各スタンバイ(またはpg_receivewal等のクライアント)ごとに1プロセス起動し、WAL を継続的に送信する。同時接続数の上限は max_wal_senders で制御する。
- WANサービス(専用線・広域イーサ)
- 拠点間を接続する広域ネットワークサービス。専用線は特定区間を1社が占有し他社と物理的に完全分離される(高品質・高コスト)。広域イーサネットやIP-VPNはキャリア網を共有しつつ論理的に分離する(コスト効率が高い)。要件(分離レベル・帯域保証・コスト)に応じて選択する。
- Watch
- リポジトリの更新通知を購読する操作。Star とは別物。
- WBS(作業分解構成図)
- プロジェクトの成果物や作業を階層的に分解し、管理可能な単位のタスクへ細分化した図。担当・工数・スケジュールの割り当てや進捗管理の基礎になる。
- Web Application Firewall(Azure WAF)
- Application Gateway(リージョン内)または Front Door(グローバルエッジ)上で動き、SQL インジェクションや XSS など L7(アプリ層)攻撃を防ぐ。OWASP のマネージドルールセットと、地域遮断やレート制限などのカスタムルールを組み合わせる。導入時は検出(Detection)モードで誤検知を確認し、防御(Prevention)へ切り替える。NSG/Firewall が L3/L4 なのに対し WAF は L7。
- Web ロール
- Power Pages の訪問者(匿名/認証済み)に割り当てる役割。テーブルのアクセス許可と結び付けて、誰が何を見られる/送れるかを決める。
- Web3層モデル
- Web サーバー・APサーバー・DBサーバーの3層に役割を分割するシステムアーキテクチャ。各層を独立してスケールでき、変更の影響範囲を層内に閉じ込めやすい。
- WebAuthn(パスワードレス認証)
- FIDO2の一部としてW3Cが標準化した、公開鍵暗号に基づくWebのパスワードレス認証API。認証器(生体センサやセキュリティキー)が秘密鍵を保持し、サーバへは公開鍵のみを登録するため、フィッシングやパスワード流出に強い。
- Webhook
- リポジトリ/組織のイベント発生時に外部 URL へ HTTP 通知を送る仕組み。CI 連携・SIEM・チケット起票などの自動化に使う。
- webhook(Dataverse)
- Dataverse のイベントを任意の HTTP エンドポイントへリアルタイムに POST する送信先。Plug-in Registration Tool で登録する。Service Bus/Event Hub と使い分ける。
- webinar(ウェビナー)
- 登録フォームで参加者情報を収集し、出欠を管理できるオンラインイベント形式。発表者が中心となり視聴者は基本的に視聴する側に回るが、Q&A やチャットで限定的に発表者とやり取りできる点が、参加者全員が対等な通常のオンライン会議(meeting)との違い。開催後は登録者・出席者のレポートを取得できる。想定規模は最大で数千人程度。マーケティングやトレーニングなど、発表中心かつ出欠管理が必要な場面に向く。
- Webサーバー
- HTTP/HTTPS でクライアントからのリクエストを受け付け、静的コンテンツを返したり動的処理を APサーバーへ振り分けたりするサーバー。Apache や nginx が代表例。
- Well-Architected の6本柱
- 優れた設計の評価軸。運用上の優秀性(運用・自動化)/セキュリティ/信頼性(障害耐性・回復)/パフォーマンス効率/コスト最適化/持続可能性(環境負荷)。Well-Architected Tool でレビューし、リスクを洗い出す。
- Wi-Fi 6(IEEE802.11ax)
- 無線LAN規格IEEE802.11ax。OFDMA(直交周波数分割多元接続)により1チャネルを複数のリソース単位に分割して複数端末へ同時多重伝送でき、多数の端末が混在する環境での実効スループットを大きく改善する。6GHz帯を使うWi-Fi 6Eもある。
- Wi-FiとIEEE802.11
- Wi-Fiは無線LAN機器の相互接続性を認証するWi-Fi Allianceのブランド名で、実体はIEEE802.11規格群に基づく。IEEE802.11にはb/g/n/ac/ax/be等の規格があり、それぞれ2.4GHz・5GHz・6GHz帯を使い分けて通信する。
- Wiki とリポジトリインサイト
- Wiki でプロジェクトの長文ドキュメントを管理し、README で概要を示す。Insights でコントリビューションやトラフィック、依存関係グラフなどリポジトリの状態を可視化する。
- Windows 365(クラウド PC)
- クラウド上の PC(デスクトップ)を任意のデバイスに配信し、どこからでも同じ環境を使えるサービス。
- Windows Autopatch
- Windows・Microsoft 365 Apps・Microsoft Edge・Teams の更新リング管理と展開監視を Microsoft が肩代わりするマネージド更新サービス。デバイスは自動的に4つの既定デプロイメントリング(Test/First/Fast/Broad)へ振り分けられ、問題発生時は Microsoft 側で一時停止・調査する。IT 部門の更新管理工数を削減するのが狙い。
- Windows Autopilot
- 既存ハードウェアを再利用し OOBE で Microsoft Entra join + Intune 登録 + 構成を自動化する(従来のイメージングを置換)。モードは user-driven(ユーザーがサインインして自分用構成)/ pre-provisioning(IT が事前準備)/ self-deploying(操作なし・キオスク向け)。
- Windows Defenderとホストベースファイアウォール
- Windows Defender(現在はMicrosoft Defender Antivirusに改称)は、Windowsに標準搭載されているマルウェア対策・脅威検知ソフトウェア。ホストベースファイアウォールは、ネットワーク境界ではなく個々の端末(ホスト)にインストールし、その端末単位で通信を許可・拒否するファイアウォール(Windowsファイアウォール等)。
- Windows Event Forwarding(WEF)
- 多数の Windows サーバーのイベントをコレクター(WEC)に転送して集約し、そこから AMA で Sentinel に取り込む構成。各サーバーに個別エージェントを入れる代わりに、規模に応じて集約してから収集する。
- Windows Hello for Business
- 生体認証(顔・指紋)や PIN を用いてパスワードレス認証を実現する仕組み。資格情報をデバイスにひも付け、フィッシング耐性を高める。
- Windows LAPS(Local Administrator Password Solution)
- 端末ごとに固有のローカル管理者パスワードを自動でローテーション/保管する仕組み。パスワードの使い回しによる横移動を防ぐ。Entra/Azure ロールの特権昇格を担う PIM とは別レイヤ。
- Wiresharkとパケットキャプチャ
- ネットワーク上を流れるパケットを取得・解析するオープンソースのパケットアナライザ。取得結果は.pcap形式で保存でき、各層のヘッダーやペイロードを詳細に確認できるため、通信トラブルの原因調査やプロトコルの学習に使われる。
- WLC(Wireless LAN Controller)
- 複数の軽量AP(Lightweight AP)を一元的に集中管理する装置。SSID・無線チャネル・電波出力・ローミングなどの設定と制御をWLCに集約することで、AP単体では個別設定していた作業を自動化・一元化できる。
- workflow_call(再利用可能ワークフロー)
- 他のワークフローから uses: で呼び出せるようにするトリガー宣言。呼び出し側は with: で入力、secrets: でシークレット(inherit 可)を渡し、outputs を受け取れる。
- workflow_dispatch
- UI/API/CLI から手動で起動するトリガー。inputs に type/required/default/options を定義して起動時にパラメーターを受け取れる。
- Workflows
- サービス間の軽量なステップ連携(シンプルなワークフロー)を行うサーバーレスのオーケストレーション。重い依存は Cloud Composer。
- Workforce Identity Federation
- 外部 IdP(Okta/Azure AD など)で管理する「人間のユーザー」の ID を、Google アカウントを作成せずに Google Cloud のアクセスへ連携する仕組み。ワークロード向けの Workload Identity Federation と取り違えない。
- Workload Identity Federation(GCP)
- AWS・Azure・オンプレミス・CI/CD(GitHub Actions 等)といった Google Cloud 外部の ID プロバイダを信頼し、その発行するトークンと引き換えに一時的な Google Cloud 認証情報を得られる仕組み。サービスアカウント鍵のダウンロード・配布を避けたい外部システム連携で使う。
- Workspace のエディション
- Business(Starter/Standard/Plus)や Enterprise などの契約区分。利用できる高度なセキュリティ/コンプライアンス機能(DLP・Vault・コンテキストアウェアアクセス等)はエディションに依存する。
- WPA(Wi-Fi Protected Access)
- 無線LANの暗号化・認証規格。WEPの脆弱性を受けて登場した初代のWi-Fi Protected Access(WPA)はTKIPを使うが現在は非推奨で、より強固なWPA2・WPA3への移行が進んでいる。
- WPA2-PSKとWPA2-Enterprise
- WPA2には認証方式が2種類ある。WPA2-PSK(WPA2-Personal)は全端末が共通の事前共有鍵(パスフレーズ)で認証する簡易な方式で家庭・小規模拠点向き、WPA2-Enterpriseは802.1X/RADIUSで端末・利用者ごとに個別認証する方式で、大規模組織や利用者単位のアクセス管理に向く。
- WPA3とSAE
- 無線LANのセキュリティ規格WPA3が採用する鍵確立方式SAE(Simultaneous Authentication of Equals、Dragonfly)。WPA2-PSKの4ウェイハンドシェイクが抱えたオフライン辞書攻撃の弱点を、通信傍受だけでは総当たり検証できない方式で解消する。
- Write Accelerator
- M シリーズ VM の特定ディスクの書き込み遅延を下げる機能。主に SAP HANA のトランザクションログディスクに使う。読み取りキャッシュやデータディスク用ではない点に注意。
- X Window System(X サーバー/X クライアント)
- Linux の GUI の土台となるサーバー/クライアント方式の仕組み。X サーバーは画面・入力のある側で動き描画と入力を提供、X クライアントはアプリ本体。アプリが動く場所と表示する場所を分離できる。
- X の管理3層(ディスプレイマネージャー/ウィンドウマネージャー/統合デスクトップ環境)
- X の管理3層。ディスプレイマネージャー(GDM 等)はグラフィカルなログイン画面、ウィンドウマネージャーは窓の枠・移動・重なり、統合デスクトップ環境(GNOME/KDE)はアプリ一式を含むデスクトップ全体。startx はディスプレイマネージャーを使わず手動で X を起動する。
- X-Ray のサンプリングとサブセグメント
- サンプリング=全リクエストでなく一部だけトレースし、オーバーヘッドとコストを抑える(ルールで率を制御)。セグメント/サブセグメント=1 トレース内のサービス区間/内部処理(DB 呼び出し等)。アノテーションでフィルタ用のメタデータを付ける。
- X.509証明書・暗号スイート・鍵交換
- X.509はデジタル証明書の標準フォーマットで、発行者・有効期間・公開鍵・署名などを含む。暗号スイートはTLSの通信で使う暗号アルゴリズムの組み合わせを指す名前で、TLS1.2までは鍵交換方式・署名方式・対称暗号・ハッシュ関数をまとめて表したが、TLS1.3では暗号スイートは対称暗号+ハッシュのみを表し、鍵交換(ECDHEが標準で前方秘匿性を提供)や署名はネゴシエーションで別途決まる。鍵交換は通信の両者が第三者に知られずに共有の対称鍵を安全に確立する手順(Diffie-Hellman/ECDHE等)。
- xargs/tee
- xargs は流れてきたテキストを次のコマンドの引数に変換する(find … | xargs rm)。標準入力を読まないコマンドへ値を渡す橋渡し。tee はストリームを画面とファイルの両方へ複製する。
- XML
- タグで階層構造を表すマークアップ言語。NETCONFのメッセージ形式として使われるほか、機器の構成をXML文書として表現する場面もある。JSONより冗長だが、スキーマ(XSD)による厳密な検証やコメントの記述ができる点が異なる。
- XMLA エンドポイント
- セマンティックモデルへ外部ツール(Tabular Editor 等)から接続・デプロイ・管理するための接続点。大規模モデルの運用に使う。
- XP(エクストリームプログラミング)
- アジャイル開発の代表的な手法の一つで、少人数チームでの反復的な開発と変化への対応を重視する。ペアプログラミング、テスト駆動開発(TDD)、リファクタリング、継続的インテグレーション、小さなリリースなどのプラクティスを特徴とする。スクラムがプロジェクト運営の枠組み中心なのに対し、XPは開発の技術的プラクティスに重きを置く。
- YAML
- インデントで階層を表す、人が読み書きしやすいテキスト形式。CloudFormation や各種 IaC ツール、CI/CD パイプラインの設定ファイルで好まれ、同じデータを JSON とも相互変換できる。
- YAML アンカー / エイリアス
- 同一ファイル内で繰り返す断片を再利用する YAML 機能(アンカー & / エイリアス * / マージキー <<)。パーサーが展開してから評価される。複数ファイル間の共有には使えない(その場合は再利用可能ワークフロー)。
- YAML パイプラインとテンプレート
- パイプラインをコード(YAML)で定義し、ステージ・ジョブ・ステップで構成する。テンプレートで共通処理を再利用し、マルチステージで CI と複数環境への CD を 1 本にまとめる。
- YARA-L 検出ルール
- Google SecOps で不審な振る舞いを検出するルール記述言語。リファレンスリスト(既知値の一覧)やエンティティ/コンテキストデータと組み合わせて精度を高める。
- yum/dnf(RHEL 系)
- RHEL/CentOS 系のリポジトリ利用パッケージ管理(後継が dnf)。yum update はパッケージ本体を更新(索引は自動更新)、install/remove/search/info。provides でファイルを提供するパッケージを逆引き、yumdownloader は取得のみ。リポジトリ定義は /etc/yum.repos.d/ の .repo ファイル、全体設定は /etc/yum.conf。
- Z-Order(データスキッピング)
- よく絞り込む列でデータを近くに並べ、読まなくてよいファイルを飛ばせる(データスキッピング)よう最適化する手法。
- .github/workflows
- リポジトリ内でワークフロー YAML を置く既定のディレクトリ。ここに置かれた YAML が Actions として認識される。
- .gitignore
- 追跡したくないファイル/パターン(ビルド成果物・依存・秘密情報など)を除外する指定ファイル。
- /dev/null
- 書き込んだデータをすべて捨てる特殊デバイス。不要な出力の破棄に使う(2> /dev/null でエラーを非表示)。
- $GITHUB_ENV
- 実行時に生成した値を環境変数として後続ステップへ渡す特殊ファイル。echo "KEY=value" >> "$GITHUB_ENV" のように追記する。
- $GITHUB_OUTPUT
- ステップ出力を設定する特殊ファイル。echo "name=value" >> "$GITHUB_OUTPUT" で書き、同一ジョブ内は steps.<id>.outputs.<name> で参照。短い値の受け渡しに使う。
- $GITHUB_STEP_SUMMARY
- Markdown を追記すると実行ページにリッチなジョブサマリー(テスト結果表・カバレッジ・リンク等)として表示される特殊ファイル。
- アーカイブと圧縮(tar/gzip/bzip2/xz)
- tar は複数ファイルを1つにまとめる(作成 cf/展開 xf/一覧 tf)。圧縮を併用するオプションは z=gzip・j=bzip2・J=xz(例 tar czf a.tar.gz dir)。gzip/bzip2/xz は単体で1ファイルを圧縮する(まとめる機能はない)。dd はブロック単位の低レベルコピー。
- アーキテクチャパターン
- システム全体の構造に関して繰り返し現れる問題への、再利用可能な解決の型。レイヤ、クライアントサーバ、イベント駆動、マイクロサービス、パイプフィルタなどが代表例で、それぞれ長所短所と適用文脈をもつ。デザインパターンがクラス・オブジェクト粒度の設計を扱うのに対し、アーキテクチャパターンはより粗い全体構造を扱い、アーキテクトが品質特性の要求に照らして選択する。
- アーティファクト(artifact)
- ビルド成果物・テストレポート等のファイルを実行に紐づけて保存する仕組み。upload-artifact で保存、download-artifact で取得。保持期間(retention)後に自動削除。ジョブ間でファイルを渡す標準手段。
- アーティファクトのアテステーション/来歴(provenance)
- ビルド成果物が「どのワークフロー/コミットから作られたか」を証明・検証する仕組み。SLSA などの枠組みでサプライチェーンの完全性を高め、デプロイ時に検証して改ざん成果物を防ぐ。
- アイコン(コントロール)
- 矢印・ゴミ箱・編集などの記号アイコンを表示し、押して操作を実行できるコントロール。小さな操作ボタンとして使う。
- アイテム権限(Fabric)
- 個々のアイテム(レイクハウス/レポート等)を、ワークスペースロールとは別に特定ユーザーへ共有・権限付与する仕組み。
- アイデンティティベースポリシー
- IAM のユーザー・グループ・ロールにアタッチし、「そのプリンシパルが何をできるか」を定義するポリシー。マネージドポリシー(AWS管理/カスタマー管理)とインラインポリシーがあり、同一アカウント内の権限付与の基本形になる。
- アカウント管理のライフサイクル
- 利用者アカウントを入社(発行・権限付与)、異動(権限の見直し・棚卸し)、退職(速やかな無効化・削除)という一連の流れで管理すること。退職者アカウントの削除漏れや異動後の旧権限の残存は、内部不正や不正ログインの温床になるため、人事情報と連動した棚卸しが重要となる。
- アカウント情報ファイル(/etc/passwd/shadow/group)
- アカウント情報を持つ3ファイル。/etc/passwd はユーザー基本情報(全員が読める・パスワード本体は持たない)、/etc/shadow はハッシュ化パスワードとエージング情報(root のみ可読)、/etc/group はグループとメンバー。確認は id(UID/GID/所属)や getent(NSS 経由で LDAP 等も含む)。パスワード設定は passwd。
- アクション
- トリガー後に実行する処理(例:ファイル保存、通知、承認、データ更新)。コネクタ経由で外部サービスを操作し、複数を順に並べる。
- アクションの種別(JavaScript/Docker/コンポジット)
- JavaScript アクション(Node.js・クロスプラットフォーム・速い)、Docker コンテナアクション(環境を同梱できるが Linux ランナー限定・起動は遅め)、コンポジットアクション(ステップの束)の 3 種。
- アクション入力(INPUT_/getInput)
- with: で渡した入力をアクション内で読む方法。環境変数 INPUT_<名前>、JavaScript アクションでは @actions/core の getInput を使う。
- アクション利用ポリシー
- 使えるアクションの範囲を統制する組織/Enterprise 設定。すべて無効/すべて許可/GitHub 製のみ/GitHub 製+検証済み/特定アクションの許可リスト、から選ぶ。外部アクションの SHA ピン留め必須化も可能。
- アクセシビリティ
- 障碍のある利用者も使えるよう配慮した設計(コントラスト・代替テキスト・キーボード操作・スクリーンリーダー対応)。Power Apps にはアクセシビリティチェッカーがある。
- アクセスアドバイザー(最終アクセス情報)
- IAM の機能で、ユーザー/ロール/ポリシーが各サービスに最後にアクセスした日時(last-accessed 情報)を表示する。使われていない過剰な権限を特定し、最小特権へ絞り込むのに使う。
- アクセスコントロールの評価
- システム監査において、認証(本人確認)、認可(権限付与)、最小権限の原則、特権ID(管理者権限)の管理などアクセス統制の整備・運用状況を監査人が評価すること。付与された権限が職務内容に対して過剰でないか、権限の棚卸しが定期的に行われているかなどを検証する。
- アクセスパッケージ(エンタイトルメント管理)
- ある役割に必要なアクセス(グループ・アプリ・SharePoint)の束を定義し、誰が申請でき・誰が承認し・どれだけの期間有効かをポリシーで決める。My Access でセルフサービス申請し、期限切れで自動失効する。
- アクセスポートとトランクポート
- アクセスポートは単一VLANにのみ属するスイッチポートで、フレームにVLANタグを付与せず端末を収容する。トランクポートは複数VLANのフレームを1本の物理リンクで転送するポートで、IEEE 802.1Q等でVLANタグを付与して識別する。トランクではネイティブVLAN(タグなしで転送する既定VLAN)の不一致がセキュリティ上の問題(VLANホッピング等)を招きうる。
- アクセスレビュー
- 既存アクセス(グループ/アプリ/ロール/ゲスト)を定期的に「まだ必要か」見直し、不要を剥奪する仕組み。自動適用で否認を自動剥奪でき、PIM 連携で特権ロールを棚卸しする。エンタイトルメント管理(入口)と対をなす継続的な棚卸し。
- アクセスログ
- Web サーバーが受け付けたリクエスト(アクセス元・時刻・URL・ステータスコード等)を記録するログ。Apache では既定で access_log に出力される。
- アクセス管理(RBAC / 最小特権 / JIT)
- ロールベースアクセス制御(RBAC)で職務に応じた権限を付与し、最小特権の原則を適用、PIM のジャストインタイム(JIT)昇格で特権を必要時のみ有効化する。
- アクセス許可(GRANT/DENY/REVOKE・最小権限)
- 固定/カスタムのデータベースロールと GRANT/DENY/REVOKE で securable ごとに権限を付与する。DENY が優先され、最小権限を全 securable に適用する。
- アクセス許可境界(Permissions Boundary)
- IAM ユーザー/ロールに付与できる権限の上限を定めるポリシー。権限を付与するのではなく、実効権限を「アイデンティティポリシー ∩ 境界」に制限する。権限委任時の過剰付与を防ぐのに使う。
- アクセス制御(最小権限・職務分離)
- 誰がどの情報資産に対しどの操作を許可されるかを管理する仕組み。基本原則として、業務に必要な最小限の権限だけを与える最小権限の原則と、不正や誤りを防ぐため一連の業務を複数人で分担させる職務分離がある。認証・認可・監査(ログ記録)と組み合わせて運用する。
- アクセス層(Hot/Cool/Cold/Archive)
- Blobの保存コストをアクセス頻度で最適化する層。下にいくほど保存は安く、取り出しは遅く割高。
- アクセラレーテッド Site-to-Site VPN
- AWS Global Accelerator のエッジロケーションを経由して VPN トラフィックを AWS のバックボーンネットワークに早期に乗せることで、インターネット区間の遅延とジッターを減らすオプション。地理的に離れた拠点からの接続や、遅延に敏感なワークロードで有効。
- アクティビティ図
- UMLの振る舞い図の一つで、業務や処理の一連の流れをアクション(丸角の箱)の連なりとして表す。分岐・合流や並行処理(フォーク/ジョイン)を表現でき、スイムレーンで担当者や役割ごとに処理を区分できるため、業務フローや処理手順のモデル化に適する。1つのオブジェクトの状態変化を表す状態遷移図とは目的が異なる。
- アクティブ geo レプリケーション
- 別リージョンに読み取り可能なセカンダリを非同期に作る DR 機能。手動フェイルオーバーでき、最大4つのセカンダリを持てる。
- アジャイル開発とスクラム
- アジャイル開発は、短い期間(イテレーション)で計画・設計・実装・テストを繰り返し、変化する要求に柔軟に対応する開発手法の総称。スクラムはその代表的な手法の一つで、スプリントと呼ぶ短い期間を繰り返す。
- アダプションスコアと使用状況分析
- Microsoft 365 の活用度を可視化する指標。コラボレーションやコンテンツ作成などの利用状況を分析し、定着促進の打ち手につなげる。
- アドミニストレーティブディスタンス(AD)
- 複数のルーティングプロトコル(経路情報源)間で、どの経路情報をより信頼できるとみなすかを示す値。小さいほど優先される。同一プレフィックス長の経路が複数プロトコルから学習された場合、メトリック比較の前にADで情報源の優先順位を決める(例:静的1・OSPF110・RIP120)。
- アドレスクラスとパブリックアドレス
- IPv4アドレスは先頭ビットのパターンによりクラスA〜Eに分類され(クラスAは1〜126、クラスBは128〜191、クラスCは192〜223で始まる等)、クラスによって既定のネットワーク部/ホスト部の境界が決まる。プライベートアドレスと異なりインターネット上で一意にルーティングされるアドレスをパブリックアドレスと呼ぶ。
- アノテーション
- ログ上でエラーや警告を要約表示し、該当行へジャンプできる表示。失敗の原因特定に役立つ。
- アプリ セットアップ ポリシー(app setup policy)
- アプリをユーザーのバーにピン留めしたりプリインストールしたりして見せ方を制御する。使用可否を制御する app permission policy とは別。
- アプリアクセス制御(API アクセス管理)
- Marketplace アプリやサードパーティの連携アプリが Workspace データへアクセスする可否を制御し、信頼するアプリだけに限定して未確認アプリをブロックする仕組み。サービスのオン/オフとは別レイヤー。
- アプリケーショングループ
- Azure Virtual Desktop でユーザーに公開する単位。デスクトップアプリグループ(フルデスクトップ)と RemoteApp グループ(個別アプリ)の 2 種類があり、ユーザー/グループを割り当てて公開し、ワークスペースでまとめて見せる。
- アプリケーションコントロール(IT業務処理統制)
- 個別の業務システムにおいて、入力・処理・出力の正確性・網羅性・正当性を確保するための統制。チェックディジットによる入力誤り検出、バッチコントロール(件数・金額の突合)、入力データの妥当性チェック、エラーの再処理管理などが含まれる。監査人は業務プロセスに組み込まれた自動化・手動の統制がリスクに対応しているかを評価する。
- アプリケーションセキュリティグループ(ASG)
- VM の NIC を役割(web・db 等)でグループ化し、NSG 規則で IP の代わりに ASG 名を指定できる仕組み。IP 管理を減らし規則を読みやすくする。
- アプリケーションデフォルト認証情報(ADC)
- アプリが Google Cloud へ認証する際の標準的な資格情報の解決方法。サービスアカウントや Workload Identity Federation と組み合わせ、鍵の直書きを避ける。
- アプリケーションマスキング(app masking)
- 同じイメージ上のアプリを、ユーザー/グループごとに「見せる・隠す」FSLogix の機能。1 つのゴールデンイメージで複数の利用者層に異なるアプリ可視性を与えられ、ライセンス制御にも使える。アプリを動的に配信する App attach とは別物。
- アプリのアクセス許可と同意(OAuth)
- エンタープライズアプリへのアクセスを OAuth のアクセス許可付与で管理する。アクセス許可スコープを構成し、ユーザー同意か管理者の同意かを制御してリスクの高い委任を防ぐ。
- アプリの共有
- 作成したアプリを他のユーザーやグループに使わせる設定。利用者には実行権限を、共同編集者には編集権限を与える。データ側の権限とは別に管理する。
- アプリの種別(Win32 / LOB / Microsoft Store)
- Win32 app は .intunewin パッケージに変換した従来型デスクトップ アプリ。line-of-business(LOB)app は自社開発の業務アプリ。Microsoft Store app はストア配信のアプリ。形式で展開方法を選ぶ。
- アプリ許可ポリシー(app permission policy)
- どのアプリをユーザーが使えるか(Microsoft/サードパーティ/カスタム別に許可/ブロック)を制御する。ピン留め/プリインストールの app setup policy とは別。
- アプリ構成ポリシー
- 管理対象アプリの動作設定(サーバー接続先 URL、既定のサインインドメイン、機能のオン/オフ等)を事前にプッシュ配布し、ユーザーに手動設定させずに済む仕組み。マネージド デバイス向けとマネージド アプリ(MAM)向けの2種類があり、アプリ保護ポリシーとは異なりデータ保護ではなくアプリの設定値そのものを配る役割。
- アプリ登録とエンタープライズ アプリ
- アプリ登録は、アプリを Entra ID に登録する設計図(テンプレート)。エンタープライズ アプリケーションは、その登録を各テナントで実体化したサービスプリンシパルで、サインインやアクセス許可を表す。
- アプリ保護ポリシー(MAM)
- MAM(Mobile Application Management)によりアプリ内の組織データを保護するポリシー。対象アプリからのコピー/貼り付け制限、暗号化、アクセス用 PIN/生体認証、他アプリへのデータ持ち出し制限(データ保護のみ)等を設定する。デバイス登録が不要なため未登録の BYOD 上のアプリでも適用でき、退職時にはアプリ単位で組織データだけを選択的にワイプできる。
- アベイラビリティーゾーン(AZ)
- リージョン内の独立した1つ以上のデータセンター(電源・冷却・NWが分離)。複数AZへ分散すると高可用性になる。
- アムダールの法則
- プログラム全体の高速化率は並列化できない逐次部分の割合で上限が決まるという法則。並列化率pのうち逐次部分(1-p)が残るため、プロセッサ数を無限に増やしても速度向上は1/(1-p)に漸近する。並列化投資の効果を見積もる計算問題の頻出テーマ。
- アラート ルール(alert rules)
- Teams 管理センターの「通知とアラート」>「ルール」で設定する、デバイス/リソースの正常性を監視する仕組み。代表例は Device state rule で、Teams Rooms や SBC(Session Border Controller)などの状態が Unhealthy(異常)に変化した際に管理者へ通知を送る。利用状況やアクティブユーザー数などの量的指標のしきい値超過を通知するものではなく、レポートを能動的に見に行く usage reports に対し、こちらは機器の健全性に特化した受動的な通知の仕組み。
- アラートチューニング
- Microsoft Defender XDR で、既知の良性アクティビティや誤検知パターンに一致するアラートを条件付きで自動的に解決・抑制するルール(旧称:抑制ルール)。組織固有の正当な挙動(承認済みツール等)によるノイズを減らし、アナリストの注意を真の脅威へ集中させる。
- アラートと通知(Intune)
- compliance drift(準拠状態の悪化)、enrollment failures(登録失敗の急増)、configuration conflicts(構成の競合)などの事象を検知したときに、あらかじめ設定した alert rules に基づき管理者へ通知する Intune の機能。レポートの可視化とは別に、閾値超過時に能動的に知らせる通知系の役割を担う。
- アラートの dismiss(却下)と所有権
- アラートの却下は誤検知や許容できる場合に理由を記録して慎重に行う(安易な却下はリスクの放置)。所有権を明確にして誰が対応・修復するかをはっきりさせ、放置や重複対応を防ぐ。
- アラート設定(Fabric)
- 更新失敗や条件成立などを検知して通知する設定。Data Activator や監視機能と組み合わせて運用を自動化する。
- アラームの欠落データ処理 / 評価期間
- アラームの設計要素。評価期間(N データポイント中 M 超過で発報)でフラッピングを抑える。欠落データの扱い(notBreaching/breaching/ignore/missing)でデータが来ない時の状態を決める。SOA 頻出の調整ポイント。
- アローダイアグラム
- 作業の順序関係と所要日数を矢印とノードで表した図(PERT図)。各経路の日数を積み上げることで、クリティカルパスや最早・最遅の開始・終了日を算出できる。
- アンサンブル学習(バギング/ブースティング)
- 複数モデルを組み合わせて精度を上げる手法。バギング(並列・分散低減・ランダムフォレスト)とブースティング(逐次・バイアス低減・XGBoost)が代表。
- アンゾフの成長マトリクス
- 「製品」と「市場」が既存か新規かの2軸で事業の成長戦略を、市場浸透(既存製品×既存市場)・新製品開発(新規製品×既存市場)・新市場開拓(既存製品×新規市場)・多角化(新規製品×新規市場)の4パターンに整理するフレームワーク。ストラテジストは自社の強みを活かせるか・リスク許容度はどの程度かを踏まえ、どの成長方向を選ぶべきかを判断するために用いる。多角化はリスクが最も高く、既存資源との関連性(シナジー)の見極めが成否を分ける。
- アンチパスバック
- 入退室管理で、入室記録のない人物の退室や、在室中の人物のカードでの重複入室といった論理的に矛盾する通行を検知・禁止する仕組み。1枚のカードを外部で受け渡して複数人が入室する共連れ的な不正利用を防ぐ。
- イーサネット
- IEEE 802.3で標準化されたLANのデータリンク層〜物理層技術で、MACアドレスによるアドレッシングとイーサネットフレームによるデータ転送を行う。当初はCSMA/CDによる共有バス方式だったが、現在はスイッチによる全二重専用線接続が主流であり、伝送速度は10Mbpsから400Gbpsまで規格が拡張されている。試験ではフレームフォーマットや速度規格(1000BASE-T等)の命名規則が問われる。
- イテレーター関数(SUMX 等)
- テーブルを 1 行ずつ評価して集計する DAX 関数(SUMX・AVERAGEX・MAXX 等)。行ごとの計算を合計する場面で使う。
- イノベーションと破壊的イノベーション
- イノベーションは、技術や仕組みの革新によって新たな価値を生み出すこと。既存製品の性能を段階的に向上させるものを持続的イノベーションと呼ぶのに対し、破壊的イノベーションは、当初は性能が劣っても簡便・低価格などの新たな価値で既存の市場や製品を置き換えてしまう革新を指す。
- イノベーションのジレンマ
- 業界のリーダー企業が、既存の優良顧客の声に真摯に応えて持続的技術に磨きをかけるほど、当初は性能が低く低価格・簡便といった新たな価値を持つ破壊的技術への対応が遅れ、結果としてその破壊的技術に市場を奪われてしまう現象。ストラテジストは、既存事業の合理的な経営判断の積み重ねがかえって将来の脅威を見誤らせるという逆説を踏まえ、既存事業とは別枠で破壊的技術を育てる仕組み(別組織化など)の要否を検討する。
- イノベータ理論(普及曲線)
- 新しい製品・技術が市場に普及していく過程を、採用の早い順にイノベーター・アーリーアダプター・アーリーマジョリティ・レイトマジョリティ・ラガードの5類型に分類する理論。ストラテジストは、自社製品が今どの採用者層に届いているかを踏まえ、初期市場ではイノベーターやアーリーアダプターの評価に訴える先進性重視の施策を、普及期には多数派に訴える実績・信頼性重視の施策へ転換すべきと判断する。
- イベントソーシング
- 現在の状態そのものではなく、状態を変化させた一連のイベントを真実の記録として保存する設計パターン。任意の時点の状態はイベントを最初から再生して復元でき、変更履歴がそのまま残るため監査性に優れる。ストリーミングやイベント駆動基盤と相性が良い。
- イベントソースマッピングと送信先
- SQS/Kinesis/DynamoDB Streams をポーリングして Lambda を起動するイベントソースマッピング。バッチサイズ/ウィンドウを調整し、失敗は送信先(Destinations)や DLQ へ振り分ける。
- イベントデータとエンティティデータ
- イベントデータは「いつ何が起きたか」の行動記録(Cloud Audit Logs 等)、エンティティデータは「誰/どの資産か」の文脈(Active Directory 組織コンテキスト等)。エイリアシングフィールドで複数識別子を名寄せしてからエンリッチする。
- イベントフラグ
- 複数のビットで構成され、各ビットが特定のイベント発生を表す同期オブジェクト。タスクは特定のビットパターン(単一イベントまたは複数イベントのAND/OR条件)が成立するまで待機でき、複数の非同期イベントの組合せ条件による同期が必要な場面でセマフォより柔軟に使える。
- イベントリプレイ
- アーカイブに保存されたイベントを、指定した時間範囲で再度イベントバスへ送信し直す操作。新しいイベントと同様にルールで処理されるため、障害でスキップされたターゲット処理のやり直しや、新しいルールの動作検証(バックテスト)に使う。
- イベント管理
- 監視ツールが検知したサービスや構成要素の状態変化(イベント)を、正常を示す情報・注意を要する警告・対応が必要な例外に分類し、適切な対応へつなぐプロセス。しきい値監視によりインシデントの予兆を早期に捉え、自動対応や通知の起点となる。
- イベント駆動 AI パイプライン
- Event Grid/Service Bus/Event Hubs でイベントやメッセージをトリガーに、非同期で AI 処理(取り込み→埋め込み→インデックス化→推論)をオーケストレーションする設計。
- イミュータブルインフラ
- 稼働中のサーバーを変更せず、新しいイメージ(AMI/コンテナ)で作り直して入れ替える運用方式。構成ドリフトを排除し、ロールバックは旧バージョンへ戻すだけ。Blue/Green や Auto Scaling と相性が良い。
- イメージ(Docker)
- コンテナを起動するための読み取り専用のひな型。Dockerfile から docker build で作成するか、docker commit で稼働中コンテナの状態から作成する。docker pull でレジストリから取得し、docker images で一覧、docker rmi で削除する。
- インサイダーリスク管理
- 内部関係者による情報漏洩や不正な活動のリスクを、ふるまいのシグナルから検知・管理する(プライバシー配慮)。
- インジェクション対策(プレースホルダ・サニタイジング)
- SQLインジェクションやXSSを防ぐための、入力値を安全に扱う手法群。バインド機構(プレースホルダ)は、SQL文の骨組みを先に確定させ、後から値を「データ」としてはめ込むことで、入力値をSQLの命令として解釈させない根本対策。サニタイジング(エスケープ処理)は、`<`や`'`などの特殊文字を無害な表記に変換し、命令として解釈されるのを防ぐ手法で、XSSの出力時対策として用いる。
- インシデントのライフサイクル
- インシデントが検知・記録されてからクローズされるまでの一連の段階。検知・記録、分類と優先度付け、調査・診断、解決・回復、クローズという流れで進む。各段階を確実に踏むことで対応漏れを防ぎ、履歴を残して問題管理やナレッジ蓄積に活用する。
- インシデントの優先度(影響度と緊急度)
- インシデントの対応順位を決める指標で、影響度(被害の広がりや事業への打撃)と緊急度(放置できる時間の短さ)の組合せから導く。優先度が高いものほど資源を先に割り当てる。SLAで定めた目標時間と結び付けて、限られた要員を最も効果的に配分する判断に用いる。
- インシデント管理
- サービスの計画外の中断や品質低下(インシデント)に対し、合意されたサービスレベル内でできるだけ迅速にサービスを回復させることを目的とするプロセス。記録・分類・調査・回復・クローズという流れで進め、暫定回避策も用いる。根本原因の究明は問題管理の役割であり、インシデント管理はあくまで復旧を最優先する。
- インシデント管理と調査
- 関連アラートをインシデントに相関付け、エンティティ・タイムライン・攻撃ストーリーで調査し、トリアージ→封じ込め→修復の対応を進める。
- インシデント管理と問題管理
- インシデント管理は、発生した障害を迅速に検知し、サービスをできるだけ早く復旧させる活動。問題管理は、インシデントの根本原因を特定し、再発防止策を講じる活動。目的(早期復旧 vs 再発防止)が異なる点が重要。
- インシデント対応とフォレンジック
- AWS でのインシデント対応の流れと証拠保全。準備(プレイブック/IR ロール/ログ常時有効化)→封じ込め(隔離 SG/分離 VPC・資格情報の無効化)→証拠保全(揮発性メモリ→EBS スナップショット・終了せず停止)→隔離環境で解析、の順。即終了は証拠を失う。
- インシデント対応プロセス
- セキュリティインシデントの発生に備え、検知→トリアージ(優先度判定)→封じ込め→根絶→復旧→事後レビュー(教訓の反映)という一連の流れをあらかじめ定めた手順。対応の遅れや場当たり的対応を防ぎ、被害拡大の抑止と再発防止につなげる。
- インスタンスストア
- ホストに物理接続された一時ストレージ。超高速だが、インスタンス停止/終了でデータが消える(揮発性)。キャッシュやスクラッチ領域向け。永続化が必要なら EBS を使う(SOA 頻出の対比)。
- インスタンスプロファイル(EC2 用 IAM ロール)
- EC2 に IAM ロールを渡す入れ物。アクセスキーを埋め込まず、インスタンスメタデータ経由で一時認証情報を自動取得・自動ローテーションする(漏洩リスク低減)。IMDSv2 の利用が推奨。
- インスタンスメタデータ(IMDSv2)
- EC2 のインスタンスメタデータへのアクセスにセッショントークン(PUT→GET)を必須化する方式。SSRF 脆弱性を突いてインスタンスロールの一時認証情報を盗む攻撃を防ぐ。IMDSv1 は無効化し IMDSv2 を強制するのが推奨。
- インスタンスメタデータサービス(IMDS)
- EC2 内から自身の情報(インスタンス ID・IAM ロールの一時認証情報・ユーザーデータ等)を取得できる 169.254.169.254 のエンドポイント。IMDSv2 はセッショントークンを必須化し SSRF による認証情報窃取を防ぐ(強制を推奨)。
- インスタンスリフレッシュ
- Auto Scaling グループのインスタンスを、新しい起動テンプレート/AMI へローリングで一括入れ替える機能。最小正常パーセンテージを保ちながら段階的に置換し、イミュータブルなデプロイを実現する。
- インスタントクラウドフロー
- ボタン押下など手動で起動するクラウドフロー。アプリやモバイルのボタンから任意のタイミングで実行する。
- インストルメンテーション(App Insights)
- アプリに SDK や自動計測を組み込んでテレメトリを送れるようにすること。接続文字列で送信先を指定し、カスタムイベントも追加できる。
- インターネットVPN
- 共有のインターネット回線上にIPsecやSSL/TLSでトンネルを構築し暗号化・認証によって仮想的な専用線を実現する方式。閉域網や広域イーサに比べ低コストだが、帯域・遅延はベストエフォートで品質保証がない。
- インターネットゲートウェイ(IGW)
- VPC とインターネットの間の通信を可能にする水平スケール・冗長な VPC コンポーネント。パブリックサブネットのルートテーブルが IGW を指し、リソースにパブリック IP があると双方向のインターネット通信ができる。アウトバウンド専用にしたい場合は NAT ゲートウェイ(IPv4)や egress-only インターネットゲートウェイ(IPv6)を使う。
- インタビュー法
- 被監査部門の担当者や責任者に質問し、業務の実態やシステムの運用状況に関する情報・証拠を収集する監査技法。担当者の説明を直接得られる利点があるが、発言のみでは証拠力が弱いため、記録の閲覧や現地調査など他の手続で裏付けを取ることが求められる。
- インデックス
- 特定の列の検索を高速化する仕組み。読み取りは速くなるが書き込み時の更新コストが増える。
- インデックス(CREATE INDEX)
- CREATE INDEX で作成する、検索を高速化するための補助的なデータ構造。特定列やその組み合わせに対して作成し、WHERE 句や JOIN 条件での絞り込みを高速化する。既定のインデックス種別は B-tree で、インデックスを増やすほど INSERT/UPDATE 時に索引更新の書き込みコストが増える。
- インデックス(データベース)
- 特定の列の値と行の格納位置を対応付けた補助的なデータ構造。検索を高速化できる一方、インデックス自体の維持コストがかかるため、更新頻度の高い列への設定は挿入・更新性能を低下させうる。
- インデックス/統計メンテナンス
- 断片化したインデックスの再構成/再構築と、統計の更新を定期実行して性能を保つ運用。自動化(ジョブ)でスケジュールするのが一般的。
- インデックスとインデクサー
- Azure AI Search の検索対象を定義するインデックスと、データソースから内容を取り込んで索引化するインデクサー。クエリは構文・並べ替え・フィルター・ワイルドカードに対応する。
- インデックスポリシーと複合インデックス
- Cosmos DB は既定で全プロパティをインデックスする。インデックスポリシーで included/excluded path を指定し、書き込み多は除外で更新コストを下げ、読み取り多は絞り込みパスをインデックスする。複合インデックスは複数プロパティの ORDER BY や複数フィルタを効率化する。
- インテリジェントクエリ処理(IQP)
- クエリを書き換えずに実行性能を底上げする一連の機能(適応結合・メモリ許可フィードバック・バッチモード等)。互換性レベルで有効化する。
- インバウンド NAT 規則
- フロントエンドの特定ポートへの通信を、バックエンドプール内の 1 台の VM の特定ポートへピンポイントで転送する Load Balancer の規則。RDP/SSH を個別 VM へ振り分ける用途などに使い、複数バックエンドへ分配する負荷分散規則とは目的が異なる。
- インポートモード
- データをモデルのメモリに取り込んで保持する方式。最速だが、更新スケジュールでデータを取り込み直す必要がある。
- インメモリデータベース
- データの主たる格納場所をディスクではなく主記憶(メモリ)に置くデータベース。ディスクI/Oのボトルネックがなくなり読み書きが桁違いに高速になる反面、電源断でのデータ消失に備えた永続化(ログ・スナップショット)設計が別途必要。
- インライン補完
- カーソル位置の文脈から「続き」をグレー表示で提案する機能。受け入れる(確定する)まではコードに反映されない。
- ウイルス対策ソフトの検知方式(パターンマッチング・ふるまい検知)
- パターンマッチング(シグネチャ)方式は、既知のマルウェアの特徴を記録した定義ファイル(パターンファイル)と照合して検知する方式で、既知の脅威には高精度だが定義ファイルを常に最新へ更新する運用が前提であり、定義ファイルにない未知のマルウェア(ゼロデイ)は検知できない。ふるまい検知(ビヘイビア検知)は、プログラムの挙動そのものを監視して検知する方式で、定義ファイルに依存しないため未知のマルウェアにも対応できるが、正常な処理を誤って検知する誤検知(フォールスポジティブ)が起こりうる。実務では両方式を組み合わせた多層防御が用いられる。
- ウイルス対策ポリシー(Intune)
- Microsoft Defender ウイルス対策のリアルタイム保護・クラウド提供保護・スキャンスケジュールなどをデバイスへ配布する Endpoint security のポリシー種別。マルウェアの検出・駆除に特化しており、通知/除外設定なども含む。security baseline や ASR とは別レイヤーで、検出・駆除の挙動そのものを構成する。
- ウィンドウと遅延データ(ストリーミング)
- ストリーミングでは、時間で区切って集計するウィンドウと、遅れて到着するデータ(late data)をウォーターマークと許容遅延で扱う設計が要る。バッチは溜めてまとめて処理。
- ウィンドウ関数
- GROUP BY のように行を1行へ集約せず、各行を保持したまま集計値やランクを付与できるSQL機能(OVER 句で PARTITION BY/ORDER BY を指定)。実行計画上ではウィンドウ関数のために事前に PARTITION BY/ORDER BY に基づく Sort が挿入されることが多い。
- ウィンドウ関数(ストリーミング)
- 連続するストリームを時間の窓で区切って集計する仕組み。タンブリング(重ならない)・ホッピング(重なる)・スライディング(イベント起点)などがある。
- ウェアハウス(Fabric Warehouse)
- フル T-SQL(読み書き・マルチテーブルトランザクション)に対応する Fabric の DW アイテム。データは OneLake の Delta に保存される。
- ウェアレベリング
- フラッシュメモリの書換え回数には上限があるため、特定のブロックに書込みが集中して寿命が尽きるのを防ぐ目的で、書込み先を全ブロックに分散させる技術。組込み機器のログ記録やファームウェア更新など頻繁な書換えが発生する用途で、ストレージの長寿命化に不可欠な設計要素となる。
- ウェルノウンポート
- 主要サービスに割り当てられた既定のポート番号。22 SSH・25 SMTP・53 DNS・80 HTTP・123 NTP・443 HTTPS。
- ウォーターフォールモデル
- 要件定義・設計・実装・テストといった各工程を順番に進め、原則として前工程には戻らないという前提で開発する手法。計画が立てやすい一方、途中の仕様変更には弱い。
- ウォーターマーク(増分の基準)
- 増分読み込みで「どこまで取り込んだか」を表す基準値(最終更新日時や連番など)。次回はこの値より新しい行だけを取り込む。
- ウォームプール
- Auto Scaling グループのスケールアウトに備え、事前に初期化(起動・停止/実行中)したインスタンスを別プールで待機させる仕組み。需要急増時にゼロから起動するより起動時間を大幅に短縮でき、起動処理が重いアプリで特に有効。待機中インスタンスの状態(Stopped/Running)でコストと即応性のバランスを選べる。
- ウォッチドッグタイマ(WDT)
- ソフトウェアが定期的にタイマをリセット(キック)し続けないと、一定時間で自動的にシステムをリセットするハードウェアタイマ。無限ループやデッドロックによる暴走・フリーズを検出し、自動復旧させる安全機構として組込み機器の信頼性設計に不可欠。
- エイリアス/シェルビルトイン
- エイリアスはコマンドに付ける別名(alias ll='ls -l')で、既存コマンドと同名なら優先される。シェルビルトインは cd・echo のようにシェル自身に組み込まれたコマンドで、外部の実行ファイルを持たない。
- エイリアスレコード
- ELB・CloudFront・S3・API Gateway などの AWS リソースへ、ゾーン頂点(apex)でも別名で解決させる Route 53 固有のレコード。追加課金なしで CNAME 的に機能する。
- エージェント(agentic AI)
- 単に文章を返すだけでなく、目的に向けて自律的に計画し、ツールを使い、複数ステップで行動する AI。
- エージェント(Copilot Studio)
- Copilot Studio で作る対話アシスタント(旧称ボット/チャットボット)。トピックとナレッジ、Power Automate 連携で質問対応や実処理を行う。
- エージェント(Copilot)
- 特定の業務やナレッジに特化して半自律的に作業するカスタマイズ可能な AI。組み込みの Researcher(横断的な深いリサーチ)・Analyst(データ分析・可視化)や、組織固有に作るカスタム エージェントがある。
- エージェントセッション
- Agent Mode の作業を管理する単位。進行状況の確認・中断・再開ができる。
- エージェントの管理
- エージェントは、ユーザー アクセスの構成(最小特権)→作成→承認プロセス→監視、というライフサイクルで統制する。監視は Microsoft 365 管理センターと Microsoft Power Platform 管理センターを用い、利用状況・運用インサイト・ライフサイクルを確認する。
- エージェントループ(推論→行動→観察)
- エージェントが目標達成まで「推論(次に何をするか)→行動(ツール/関数呼び出し)→観察(結果を取り込む)」を反復する制御構造(ReAct 等)。無限ループや暴走を防ぐため最大反復回数・タイムアウト・停止条件・人手承認を設ける。
- エージェント安全制御
- 自律エージェントの暴走・誤動作・濫用を防ぐ制御。停止条件・最大反復回数・タイムアウト、ツール/アクションを絞る IAM 境界(最小特権)、人手承認(human-in-the-loop)、Guardrails による入出力検査を組み合わせる。
- エージェント型自動化(Puppet/Chef)
- 管理対象の機器・サーバ上に常駐エージェントを事前導入しておき、そのエージェントがマスタへ定期的に問い合わせて構成を取得・適用するプル型の自動化方式。代表例はPuppetとChef。SSH経由でエージェント不要(エージェントレス)にプッシュ型で構成を適用するAnsibleとは対照的に、エージェントの導入・維持というコストがかかる一方、変更の定期的な自己修復に向く。
- エージング
- スケジューリングにおいて、待ち時間が長いプロセスの優先度を時間経過とともに徐々に引き上げる技法。飢餓状態の発生を防ぎ、公平性を確保する目的で用いられる。
- エージング(MACアドレステーブル)
- L2スイッチのMACアドレステーブルの各エントリに設定される寿命。一定時間(Ciscoの既定は300秒)通信のないエントリは自動的に削除(エージングアウト)され、テーブルの肥大化を防ぎ、移動した端末を正しく再学習できるようにする。
- エクスプロイト
- 脆弱性を実際に悪用し、意図しない動作(不正アクセス・権限奪取・サービス停止等)を引き起こすための具体的な手段・コード。脆弱性が「弱点」であるのに対し、エクスプロイトはその弱点を突く「攻撃の実行手段」に当たる。
- エクスペリエンス(Fabric)
- 役割別の機能セット(Data Engineering / Data Factory / Data Warehouse / Real-Time Intelligence / Power BI など)。すべて同じ OneLake を共有する。
- エコシステムへの参加(バグ報告)
- OSS への参加は段階的でよい。使用(それ自体が検証)→紹介→バグ報告→文書・翻訳・パッチ。良いバグ報告は環境(OS/バージョン)・期待動作・実動作・再現手順を添えてイシュートラッカーへ。コードを書かなくても貢献できる。
- エスカレーション(機能的・階層的)
- 一次対応で解決できない事案を上位へ引き継ぐ仕組み。より高度な専門技術をもつチームへ引き継ぐ機能的エスカレーションと、管理者へ判断や権限、経営的な意思決定を求める階層的エスカレーションがある。適切な使い分けが解決の迅速化と統制の両立につながる。
- エッジコンピューティング
- ユーザーやデータの近く(エッジ)で処理し、遅延を減らす考え方。AWS では CloudFront/Lambda@Edge/CloudFront Functions(配信エッジ)、Local Zones・Wavelength(低遅延ゾーン)、Outposts(オンプレ)で実現する。
- エッジロケーション
- コンテンツをユーザーの近くでキャッシュ・配信する拠点(Amazon CloudFront)。低遅延配信に使う。
- エッジ拡張(Local Zones / Outposts / Wavelength)
- AWS をユーザーに近づける拡張。Local Zones=大都市圏に計算/ストレージを配置、Outposts=オンプレに AWS ラックを設置、Wavelength=5G ネットワーク内に配置して超低遅延を実現する。
- エニーキャスト
- 同じ IP アドレスを複数の拠点から同時に広告し、経路的に最も近いノードへ自動的に届ける通信方式。CDN や DNS、グローバル負荷分散サービスが低遅延・高可用性を実現する基盤として使う。
- エフェメラルポート
- クライアントが接続の戻り通信用に一時的に使う高位のポート番号(一般に 1024–65535)。ステートレスなファイアウォールルール(例:ネットワーク ACL)では、戻り通信を許可するためにこの範囲を明示的に開ける必要があり、見落としやすい設定ミスの原因になる。
- エラーの特定と解決(Fabric)
- パイプライン/Dataflow Gen2/ノートブック/Eventhouse/Eventstream/T-SQL/ショートカットの各エラーを、実行ログ・エラーメッセージから切り分けて修正する運用。
- エラーバジェット
- SLOから逆算される許容可能な失敗量(1−SLO)。バジェットが残っていればリスクを取った変更を進め、使い切れば新機能より安定化を優先する、というリリース判断の共通言語として使う。ポストモーテム(非難なき事後検証)でバジェット消費の原因を学び、再発防止に活かす。
- エラーメッセージからの障害特定(FATAL/PANIC/ERROR)
- PostgreSQLのログ(log_destinationで設定した出力先)には重大度が付く。下位から DEBUG(開発者向け詳細情報)< LOG(運用上の情報)< NOTICE(利用者への軽い注意喚起)< WARNING(想定外だが処理は継続)< ERROR(当該SQL文を中止しトランザクションをアボート)< FATAL(現在の接続/セッションを切断)< PANIC(全バックエンドプロセスを巻き込んでサーバ全体をリセットし、共有メモリ破損の疑いを回避するため自動再起動を引き起こす最重度)の順に上がる。could not write to file(ディスク書き込み失敗)やout of memory(メモリ枯渇)はOSリソース枯渇の典型的な兆候として現れる。
- エラーログ
- Web サーバーの起動・設定エラーやリクエスト処理中の異常を記録するログ。Apache では error_log に出力され、障害調査の第一手がかりになる。
- エラー率
- 総リクエスト数に対する失敗リクエスト数の割合。SLIとして最もよく使われる指標の一つで、CloudWatchメトリクスやアラームのしきい値に使う。急上昇はデプロイ起因の障害やスロットリングの兆候として監視する。
- エラスティックテーブル(Dataverse)
- Azure Cosmos DB を基盤にした NoSQL 系の Dataverse テーブル。大量データ・可変スキーマ・高スループットの書き込みに向き、パーティションキーで水平スケールする。行レベルの整合性保証や一部のリレーションシップ機能は標準テーブルより制約があるため、IoT ログなど用途を選んで使う。
- エラスティックプール
- 複数の Azure SQL Database で計算リソース(eDTU/vCore)を共有し、ピークがずれる多数 DB のコストを最適化する仕組み。
- エンタープライズアーキテクチャ(EA)
- 組織全体の業務とITシステムを、ビジネス・データ・アプリケーション・テクノロジの4つの体系で統一的に可視化し、最適化する手法。業務とシステムの全体最適・整合性確保を目的とする。
- エンタープライズアクセスモデル
- コントロールプレーン/管理プレーン/データプレーンを分離し、特権を「層」で隔離する設計原則(旧 Tier モデルの後継)。PIM や PAW と組み合わせ特権アクセスを保護する。
- エンティティ
- データモデリングにおいて、業務上管理すべき対象(人・物・出来事など)を抽象化した単位。E-R図では長方形で表され、属性の集合と主キーによって個々のインスタンスが識別される。リレーショナルデータベースの表(テーブル)に対応する概念。
- エンティティ(Copilot Studio)
- 会話から取り出したい情報の型(日付・数値・都市・メールなど)。発話から値を抽出してフローや回答に渡す。
- エンティティグラフ
- Google SecOps でユーザー/資産/関係性(エンティティとコンテキスト)を結びつけ、検出ルールに文脈を与えて精度を高める仕組み。イベントをエンティティでエンリッチして調査を速める。
- エンティティ認識(NER)と PII 検出
- 固有表現認識(NER)で人名・地名・組織などを抽出し、PII 検出で個人を特定できる情報を見つけてマスキングする。
- エンドースメント(推奨/認定)
- 信頼できるアイテムに「推奨済み」「認定済み」の印を付け、利用者が良質なデータを見分けられるようにするガバナンス機能。
- エンドポイント(デバイス)管理
- 基本管理は画面ロック要求など最低限の保護、高度な管理はデバイス承認・細かいポリシー・リモートワイプまで行う。会社所有は強い管理、個人所有(BYOD)はアカウントワイプで業務データのみを保護する。
- エンドポイント(端末)
- ネットワークの末端に接続され、利用者が直接操作したりデータをやり取りしたりする機器の総称。コンピュータ・スマートフォン・IP電話・プリンタ・IoT機器・サーバーなどが含まれる。
- エンドポイントの自動スケーリング
- リアルタイム推論エンドポイントの負荷に応じてインスタンス数を増減し、コストと遅延のバランスを取る。ゼロにスケールするサーバーレス推論もある。
- エンドユーザー コンピューティング(WorkSpaces / AppStream 2.0)
- Amazon WorkSpaces はマネージドな仮想デスクトップ(DaaS)、Amazon AppStream 2.0 はアプリケーションのストリーミング配信。社内端末を持たずに安全にデスクトップ/アプリを提供する。
- エンベロープ暗号化とデータキー
- データをデータキーで暗号化し、そのデータキーを KMS のマスターキーで暗号化して保存する方式。GenerateDataKey で平文/暗号文のデータキーを取得し、平文は使用後に破棄する。
- オーケストレーション(Fabric)
- 複数の処理(パイプライン/ノートブック)を順序・依存・条件で組み合わせて自動実行すること。パラメーターと動的式で再利用性を高める。
- オーケストレーションとコレオグラフィ
- マイクロサービス連携の2つの制御様式。オーケストレーションは中央の指揮役(オーケストレータ)が各サービスを順に呼び出して全体フローを統制する方式で、流れが把握しやすい反面その指揮役に依存が集中する。コレオグラフィは中央制御を置かず、各サービスがイベントを発行・購読して自律的に連携する方式で、疎結合になる反面全体像の追跡が難しくなる。
- オートスケーラー
- 負荷に応じてサーバーの台数を自動的に増減させる仕組み。クラウドサービスの機能として提供され、スケールアウト・スケールインを自動化する。
- オーバーレイとアンダーレイ
- アンダーレイは物理スイッチ・ルータで構成される実際の転送基盤(IP到達性)を指し、オーバーレイはその上にVXLANやGREなどのトンネリングで構築される論理ネットワークを指す。オーバーレイは物理トポロジに依存せず柔軟な仮想ネットワーク・セグメンテーションを実現する。
- オープンイノベーション
- 自社内部の技術・知識だけに頼らず、社外の企業・大学・研究機関などが持つ技術やアイデアを積極的に取り込んで革新を進める経営手法。逆に自社の未活用技術を外部へ提供・ライセンスする場合もあり、内部資源だけで完結するクローズドイノベーションと対比される。
- オープンソース(OSS)
- ソースを公開し、誰もが利用・改変・再配布できる開発の考え方。
- オープンソース(OSS)
- ソースコードが公開され、使用・改変・再配布の自由が保証されたソフトウェア(自由=無料ではなく制約からの自由)。権利放棄ではなく、著作権を根拠にライセンスで条件を課す著作物であり、無保証で継続的に開発される。
- オブジェクトストレージ
- データをキーで管理し HTTP でアクセスする、事実上無限に拡張するストレージ(S3)。バックアップ・配信・データレイクに向く。階層構造ではなくフラットな名前空間。
- オブジェクトレベルセキュリティ(Fabric)
- テーブルやビューなどのオブジェクト単位でアクセス可否を制御するセキュリティ。特定のテーブル自体を見えなくする粗い粒度の制御で、列や行を部分的に見せる列/行レベルセキュリティより手前の関門として働く。ウェアハウスの GRANT/REVOKE で設定する。
- オブジェクトレベルの暗号化
- 特定の列やオブジェクトを対象に暗号化する手法(セルレベル暗号化・証明書/対称キー)。データベース全体を暗号化する TDE とは粒度が異なる。
- オブジェクト指向の三大要素(カプセル化・継承・多相性)
- カプセル化はデータと操作を1つのオブジェクトにまとめ内部を隠す性質、継承は既存クラスの性質を引き継いで新しいクラスを定義する仕組み、多相性(ポリモーフィズム)は同じ操作の呼び出しがオブジェクトの種類によって異なる振る舞いをする性質。
- オブジェクト指向分析設計(OOA/OOD)
- データ(属性)とそれに対する手続き(操作)を一体化したオブジェクトを単位に、システムを分析・設計する方法論。分析(OOA)では対象領域をクラスとその関連としてモデル化し、設計(OOD)では実装を見据えてクラス構造や責務分担、協調を具体化する。カプセル化・継承・多相性を活用し、UMLを表記に用いる。システムアーキテクトは現実世界の構造を素直に反映し、変更に強い設計を導く。
- オプショングループ
- DB エンジン固有の追加機能(Oracle の Transparent Data Encryption、SQL Server の Native Backup 等)を有効化する設定の集まり。パラメータグループがエンジン設定全般を扱うのに対し、オプショングループはエンジン向けのプラグイン的な拡張機能に限定される。主に Oracle・SQL Server 等の対象エンジンで使われ、Aurora(MySQL/PostgreSQL互換)など元々オプショングループの概念を持たないエンジンもある。
- オプティマイザ(コストベース最適化)
- 統計情報(行数・値の分布など)をもとに、同じ結果を返す複数の実行計画の候補それぞれのコスト(I/O・CPU 見積り)を算出し、最小コストの計画を選ぶ仕組み。統計情報が古い・欠落していると誤った計画を選び性能劣化を招く。
- オフライン(隔離)バックアップ
- ネットワークから物理的・論理的に切り離した状態で保管するバックアップ。常時ネットワーク接続されたバックアップ(オンラインバックアップ)はランサムウェアに暗号化・破壊される標的になり得るため、少なくとも1系統はオフライン(隔離)で保持することで、感染時にも復旧手段を確保する。3-2-1ルール(データを3つ、2種類の媒体に、うち1つはオフサイト)と組み合わせて運用されることが多い。
- オムニチャネル
- 実店舗・ECサイト・アプリ・SNSなど複数の販売・接客チャネルを統合し、顧客がどのチャネルを使っても一貫した情報と体験を得られるようにする戦略。在庫・顧客情報・購買履歴をチャネル横断で共有することで、店舗で試着してECで購入するなどの回遊行動にも対応できる。単にチャネルを並存させるだけのマルチチャネルとは異なり、顧客視点での統合体験を重視する点がストラテジストの判断ポイントとなる。
- オンデマンドキャパシティ予約
- 特定 AZ で必要なインスタンス容量を、長期契約なしに確保する仕組み。重要ワークロードや DR で「いざ起動できない」を防ぐ。Savings Plans と組み合わせて割引も適用できる(容量保証+コスト最適化)。
- オンプレミス
- サーバーやネットワーク機器を自社の施設内に設置し自ら運用する形態。クラウドと対比され、初期投資や運用の手間がかかる一方、データやシステムを自社の管理下に置ける。クラウドと組み合わせるハイブリッドクラウドの構成も一般的。
- オンプレミスデータゲートウェイ
- クラウドの Power BI からオンプレミス(や VNet)のデータソースを更新するために必要なブリッジ。クラウド SaaS ソースでは不要なことが多い。
- オンライン/オフライン移行
- オフラインは一括コピーで停止を伴う。オンラインは変更を継続同期し最後にカットオーバーするため停止が最小。許容停止時間で選ぶ。
- カーソル(SQL)
- ストアドプロシージャや埋め込みSQLの中で、問合せ結果を1行ずつ順に取り出して処理するための仕組み。集合演算が苦手な行単位の手続き的処理(1行ごとに条件分岐して更新するなど)に使う。
- カーディナリティ(リレーションシップ)
- リレーションシップの行対応の多重度。通常は一対多(ディメンションの1行がファクトの多数行に対応)で、多対多はブリッジや慎重な設計が必要。データモデル設計の基本。
- カーネル
- OS の中核。CPU・メモリ・デバイスなどのハードウェアを管理し、プロセスにサービスを提供する。仮想マシンは各自のカーネルを持ち、コンテナはホストのカーネルを共有する。
- カーネルモジュール(modprobe)
- デバイスドライバなどを必要なときだけカーネルに組み込む仕組み。lsmod でロード済みを確認、modprobe は依存モジュールごとロード/解除(第一選択)、insmod/rmmod は単体でファイルパス指定のロード/解除。
- カスタム エージェント
- 組織固有の業務やナレッジに合わせて作るエージェント。Copilot Studio などで作成し、承認プロセスを経て公開・管理する。
- カスタムコネクタ
- 標準では用意のない独自/社内の REST API を、自分で定義して Power Apps・Power Automate から呼べるようにするコネクタ。
- カスタムシークレットパターン
- 組織独自のトークンや社内システムの鍵を検出するため、正規表現で定義するパターン。既定パターンで拾えない秘密に対応する。緩すぎる正規表現は誤検知を増やすためテストで調整する。
- カスタムセキュリティ属性
- ユーザーやアプリ(サービスプリンシパル)に組織独自のキー/値(例:Sensitivity=High)を付与する分類。属性ベースのアクセス制御(ABAC)の土台になる。定義/割当には専用ロールが必要で一般管理者から分離される。
- カスタムツールチップ(レポートページツールチップ)
- 別途作成したレポートページをツールチップとして表示し、ビジュアルにホバーした際に詳細を見せる機能。
- カスタムテキスト分類
- 独自のラベル体系でテキストを分類するモデルを学習する機能。単一ラベルと複数ラベルの分類に対応する。
- カスタムメトリクス
- アプリ独自の指標を CloudWatch へ送るメトリクス。PutMetricData API、CloudWatch エージェント、または埋め込みメトリクス形式(EMF)でログから抽出して送信する。
- カスタムリポジトリロール
- 既定の Read〜Admin では粒度が合わないときに、必要な権限だけを束ねて定義できる独自のリポジトリロール。最小権限を実現しやすい。
- カスタムロール(Azure ロール / Entra ロール)
- 組み込みロールで粒度が足りないとき、必要な操作だけを許可するカスタムロールを定義する。Azure リソースロールと Microsoft Entra ロールは別系統で管理する。
- カスタム検出ルール(Defender XDR)
- Advanced Hunting の KQL クエリを昇格し、スケジュール実行で繰り返し検知+応答アクション(隔離・無効化等)を行う Defender XDR のルール。クエリはアラート/インシデント生成のため適切な entity 列を返す必要がある。Sentinel の分析ルールとは別プラットフォーム。
- カスタム質問応答(ナレッジベース)
- ドキュメントや FAQ から質問応答ペアのナレッジベースを構築し、マルチターン会話・代替表現・チットチャットを追加して公開する。多言語にも対応する。
- カプセル化と非カプセル化
- 上位層のデータに下位層のヘッダ(およびトレーラ)を順次付加してPDUを構成する処理をカプセル化、受信側で下位層から順にヘッダを取り除き上位層へ渡す処理を非カプセル化という。OSI参照モデルの各層はこの処理により独立性を保ち、下位層は上位層のデータ内容を意識せず転送できる。イーサネットフレームにIPパケットが格納され、IPパケットにTCPセグメントが格納される階層構造がその典型例である。
- カメラ(コントロール)
- 端末のカメラで写真を撮影するコントロール。点検アプリなどで撮影画像を Dataverse や SharePoint に保存するのに使う。
- カラーユニバーサルデザイン(CUD)
- 色の見え方の多様性(色覚特性の違い)に配慮し、できるだけ多くの人が情報を正しく読み取れるようにするデザインの考え方。色だけで区別せず、形・位置・文字・模様などを併用して情報を見分けられるようにするのがポイント。
- カラム指向データベース
- 行単位でなく列(カラム)単位でデータを格納する方式。同じ列の値をまとめて読めるため、特定カラムだけを集計する分析系クエリで圧縮率・読み取り性能に優れる。
- カルノー図
- 論理関数の真理値表を格子状に配置し、隣接するマスが入力1ビットだけ異なるよう並べることで、目視でグループ化しながら論理式を最簡形に簡略化できる図表。組込みのハードウェア記述や制御ロジック設計で、ゲート数削減による回路の小型化・低消費電力化に用いられる。
- かんばん方式
- 作業項目をカードとして「未着手」「作業中」「完了」などの列に可視化し、各列の作業数に上限(WIP制限)を設けて流れを管理する開発・生産管理の手法。スクラムのようなタイムボックス(スプリント)を前提とせず、完了した項目から随時次工程へ引き渡す継続的なフローが特徴。
- キーインフルエンサー(key influencers)
- ある結果(例: 解約)に最も影響する要因を自動分析して示す AI ビジュアル。次元で掘り下げて分解する分解ツリーとは目的が異なる。
- キーのローテーションとバックアップ
- Key Vault のキー/シークレット/証明書を定期的に自動ローテーションして漏えいリスクを下げ、バックアップ/復元で誤削除や障害に備える。
- キーフレーズ抽出と言語検出
- テキストから要点となるキーフレーズを抽出し、言語検出でどの言語かと信頼スコアを判定する。
- キャズム
- イノベータ理論において、初期市場(イノベーターとアーリーアダプター)とメインストリーム市場(アーリーマジョリティ以降)との間に存在するとされる、需要が一時的に途切れる深い溝。新技術・新製品が実用性や信頼性を重視する多数派に受け入れられるには、話題性や先進性を評価する初期市場向けとは異なるマーケティング・製品戦略への転換が必要になる。ストラテジストは自社製品が今どちらの市場にいるかを見極め、キャズムを越えるための施策(実績づくり・特定用途への絞り込みなど)を判断する。
- キャッシュ(actions/cache)
- 依存パッケージなど再生成可能なデータをキーで保存・復元し、ビルドを高速化する仕組み。restore-keys で部分一致復元。残したい成果物(アーティファクト)とは目的が異なる。
- キャッシュアサイド
- まずキャッシュを読み、無ければ DB から取得してキャッシュへ格納するパターン。次回以降の読み取りを高速化する。
- キャッシュ階層の設計
- CloudFront(エッジ)・API キャッシュ・ElastiCache(DB 前段)・DAX(DynamoDB 前段)を層ごとに使い、遅延とバックエンド負荷・コストを下げる設計。
- キャパシティプラン
- 将来の負荷増加を見込んで必要なリソース(CPU・メモリ・ストレージ・台数)を計画すること。スケールアップ・アウトの判断材料になる。
- キャパシティプランニング / 需要予測
- 将来の負荷を見積もり、必要な容量・コスト・スケーリング方針を計画すること。クラウドでは Auto Scaling と予測スケーリングで動的に追従できるため、固定的な過剰調達を避けられる。Compute Optimizer や CloudWatch の傾向分析が入力になる。
- キャパシティリバランス
- Auto Scaling グループの機能で、スポットインスタンスが中断されるリスクが高まったと AWS が判断した時点で、実際の中断通知を待たずに代替インスタンスを事前起動する。既存インスタンスは新インスタンスが健全になってから終了され、可用性への影響を最小化する。
- キャパシティ管理(3副次)
- サービスに必要な処理能力を、需要に見合いつつ過不足なく確保するよう計画・監視・調整する活動で、ビジネスキャパシティ管理・サービスキャパシティ管理・コンポーネントキャパシティ管理の3つの副次から成る。需要予測、しきい値監視、傾向分析を通じて将来の能力不足を先読みし、キャパシティ計画に反映する。ITサービスマネージャは事業の成長見通しと調達リードタイムを踏まえ、増強時期と規模を判断して能力不足による性能劣化を未然に防ぐ。
- キャパシティ管理とボトルネック診断
- 回線・機器のトラフィック量や利用率を継続的に監視し、将来の増設要否を予測・計画するプロセス。ボトルネック診断では、経路上の各区間の利用率・遅延・廃棄率を比較し、最も処理能力に対する負荷率が高い(待ち行列理論上ρが1に近い)区間を特定して増強対象を絞り込む。SNMPやNetFlow等によるトラフィック統計収集が実務上の基礎データとなる。
- ギャラリー
- データソースの複数レコードを一覧表示するキャンバスアプリのコントロール。テンプレートに沿って各行(アイテム)を繰り返し描画する。
- キャンバスアプリ
- 白紙のキャンバスに部品を置いて UI を自由に設計する Power Apps のアプリ種別。多様なデータソース(Excel/SharePoint/各種コネクタ)に接続でき、見た目を細かく作り込める。
- キュー(FIFO)
- 最初に格納したデータを最初に取り出すデータ構造(FIFO:First In First Out)。データは一方の端(後尾)から入れ、もう一方の端(先頭)から取り出す。窓口の順番待ち行列に例えられる。
- キュー(メッセージキュー)
- 処理待ちのメッセージやタスクを一時的に保持する仕組み。送信側と受信側の処理速度差を吸収し、非同期データ処理を支える。
- キュレート済み検出(Curated Detections)
- Google SecOps が提供する、Google の脅威リサーチに基づくマネージドな検出ルールセット。クラウド脅威やアイデンティティ脅威などをすぐに検出開始できる。
- クールダウンとウォームアップ
- クールダウンは、Auto Scaling がスケーリングアクションを実行した直後に次のスケーリング評価を一定時間抑制し、メトリクスの反映待ちによる過剰な連続スケーリング(振動)を防ぐ仕組み。ウォームアップは、新しく起動したインスタンスがターゲット追跡スケーリングの平均値計算に算入されるまでの猶予期間を指す。
- クエリツール(Azure Data Studio / SSMS)
- データベースに接続して SQL を実行・管理するツール。Windows 向けの SQL Server Management Studio(SSMS)、SQL 拡張機能を入れた Visual Studio Code、Azure ポータルや Microsoft Fabric の Web ベース SQL クエリエディターなどがある(Azure Data Studio は 2026-02-28 に提供終了)。
- クエリパフォーマンス最適化
- 実行計画・統計・適切な結合/フィルター・パーティションプルーニングなどでクエリを速くすること。ウェアハウス/SQL 分析エンドポイントで重要。
- クエリパラメーター(Power Query)
- サーバー名/パス/フィルター値などを1か所で変更できる値。開発↔本番の切替やテンプレート化に使う。
- クエリ高速化(OneLake ショートカット)
- Real-Time Intelligence で、OneLake ショートカット上のデータをキャッシュ/索引化して KQL クエリを速くする機能。標準ショートカットとの使い分けが問われる。
- クライアントサーバシステム(3層クライアントサーバ)
- 機能をサービスを要求するクライアントと提供するサーバに分担させる分散処理形態。3層クライアントサーバでは画面表示を担うプレゼンテーション層、業務ロジックを担うファンクション(アプリケーション)層、永続化を担うデータ層に分離し、各層を独立に配置・増強できる。システムアーキテクトは負荷特性やセキュリティ境界に応じて層をどのマシンへ配置するかを設計判断する。
- クラウド(クラウドコンピューティング)
- サーバやソフトウェアなどのIT資源を自分で所有せず、インターネット経由で必要な分だけ借りて利用する形態。利用者は機器の購入や保守が不要で、使った分だけ料金を払うことが多い。メールやオンラインストレージなど身近なサービスの多くがクラウドで提供されている。
- クラウドコンピューティング
- サーバー・ストレージ・ソフトなどの資源を、インターネット越しに必要なときに必要なだけ借り、使った分だけ支払う仕組み。
- クラウドサービスの提供形態(SaaS・PaaS・IaaS)
- クラウド事業者が提供する範囲によって分類される3形態。SaaSはアプリケーションそのものを、PaaSはアプリケーション実行基盤を、IaaSはサーバーやネットワークなどのインフラを、それぞれサービスとして提供する。
- クラウドの特性
- 弾力的なスケール、インターネット経由のアクセス、従量課金/サブスクリプション、自己復旧などクラウドの基本的な性質。
- クラウドフロー
- コネクタの API を使ってクラウド上のサービスを自動化する Power Automate のフロー。起点により自動・インスタント・スケジュールの 3 種類がある。
- クラウドフローテンプレート
- よくある自動化(メール添付の保存、通知、承認など)をあらかじめ組んだひな形。ゼロから作らず素早くフローを開始できる。
- クラウドワークロード保護(CWP)
- リソース種別ごと(サーバー・ストレージ・データベース・コンテナ・Key Vault・AI など)の Defender プランを有効化して実行時の脅威を検知する仕組み。Defender CSPM(事前の態勢)と対をなす2本柱。
- クラウド上の Linux 運用
- クラウドの Linux サーバーは OS の外側(電源・ネットワーク入口・物理配置)を事業者が握る。管理コンソールはインターネット経由のため多要素認証/ワンタイムパスワードで守る(漏れると全サーバーを失う)。リージョン選択は法規制・データ主権に直結し、揮発性ストレージは停止で消えるため永続データを置かない。事業者のメンテナンス(再起動)に備え自動復帰を設計する。
- クラスタ
- 複数のサーバーを協調動作させ、1つのシステムとして扱う構成。Pacemaker と Corosync などで構築し、障害時のフェイルオーバーで可用性を高める。
- クラスタリング
- 教師なし学習で、似たもの同士をグループ化する(例:顧客のセグメント化)。
- クラスタリング(HAクラスタ・負荷分散クラスタ)
- 複数のサーバを相互に連携させ、利用者からは1つのシステムとして見えるよう束ねる技術。HA(高可用性)クラスタは一部ノードが障害でも他ノードへフェールオーバーして稼働を継続することを目的とし、負荷分散クラスタは要求を複数ノードに振り分けてスループットと同時処理能力を高めることを目的とする。システムアーキテクトは可用性要求か性能要求かに応じて構成を選び、共有ディスクの有無やスプリットブレイン対策を設計する。
- クラスタ内ディレクトリ(pg_tblspc/pg_wal/pg_stat_tmp)
- データディレクトリ配下の主要ディレクトリ。pg_tblspc は各テーブルスペースへのシンボリックリンクを格納、pg_wal(PostgreSQL 10 以降の呼称。旧 pg_xlog)は WAL セグメントファイルを格納する。pg_stat_tmp は統計情報の一時ファイル格納用だったが、PostgreSQL 15 で累積統計が共有メモリ管理へ移行し廃止された(拡張互換のため空ディレクトリが作られることはあるが実際には使用されない)。
- クラスとインスタンス
- クラスはオブジェクトの設計図として属性(データ)と操作(メソッド)を定義したもの、インスタンスはクラスから実際に生成された個々のオブジェクトを指す。1つのクラスから複数のインスタンスを作成できる。
- クラッシング
- 追加の資源(要員・費用)を投入してクリティカルパス上のアクティビティ期間を短縮するスケジュール短縮技法。コスト増を伴うため、単位期間短縮あたりの追加コストが最小のアクティビティから適用するのが最適な判断となる。
- グラフデータベース
- データをノード(実体)とエッジ(関係)のグラフ構造として格納する NoSQL のモデル。SNS の友人関係やレコメンデーションのような、多対多の関係をたどる問合せを高速に処理できる。
- グラフとグラフ探索
- グラフは頂点(ノード)と辺(エッジ)の集合で表現されるデータ構造で、ネットワークや依存関係などの多対多の関係をモデル化する。グラフ探索は全頂点や特定経路を体系的に訪問する処理で、幅優先探索(BFS)はキューを用いて近い頂点から層状に、深さ優先探索(DFS)はスタックや再帰を用いて経路を掘り下げて探索する。BFSは最短経路(辺の重みが均一な場合)に、DFSは連結性判定や閉路検出に適する。
- クリアデスク・クリアスクリーン
- 物理的・人的なセキュリティ対策の一種。クリアデスクは離席時に書類や記憶媒体を机上に放置せず施錠保管すること、クリアスクリーンは離席時に画面ロックをかけ第三者が画面を閲覧・操作できないようにすること。オフィスの盗み見や置き引きによる情報漏えいを防ぐ。
- クリックジャッキング
- 透明化した罠のフレームを正規サイトに重ね、利用者が意図しないボタン(送金や設定変更等)をクリックさせる攻撃。対策としてX-Frame-OptionsやCSPのframe-ancestorsで自サイトの他ドメインからのフレーム埋め込みを禁止する。
- クリティカルセクション
- 共有資源にアクセスする処理のうち、複数のタスクや割込みハンドラが同時に実行すると不整合(競合状態)を引き起こしうる区間。実行中は割込み禁止やミューテックスによる排他制御で他からのアクセスを防ぐ必要があるが、区間を必要以上に長く取ると割込み応答性やタスク切替の遅延を招くため、最小限に留める設計が求められる。
- クリティカルパス
- プロジェクトの開始から終了までの経路のうち、最も所要日数が長い経路。この経路上の作業が1日でも遅延すると、プロジェクト全体の完了日も遅延する。
- クリプトアジリティ(暗号の危殆化対応)
- 計算機の性能向上や新たな攻撃手法の発見により、それまで安全とされていた暗号方式・鍵長が突破可能になる現象を「暗号の危殆化」という。管理者は「導入時に安全だったから今も安全」と考えず、危殆化情報を継続的に把握し、暗号方式・鍵長を計画的に更新できる体制・能力を持つ必要があり、これをクリプトアジリティと呼ぶ。近年は量子コンピュータの発展で現行の公開鍵暗号が危殆化する懸念から、耐量子計算機暗号(PQC)への計画的な移行も重要な論点となっている。
- グルーピングと自動却下(依存更新)
- グルーピングは関連する依存更新を 1 PR にまとめてノイズを減らす。自動却下は低リスクなアラートを条件で自動取り下げ(緩すぎると本物を取り下げる)。dependabot.yml で更新戦略を設定。
- グループ ポリシー分析
- 既存のオンプレミス GPO(グループ ポリシー オブジェクト)をインポートして分析し、各設定が Intune の MDM 設定として移行可能かどうかを評価する Intune の機能。非対応や非推奨の設定を洗い出すことで、クラウド移行前の計画づくりに使う(分析のみで実際の変換や適用は別作業)。
- グループと管理者ロール
- グループはメール配信・共有・権限付与をまとめて扱う単位(階層的なポリシー出し分けには使わない)。管理者ロールは特権管理者(最小限に限定)と、用途別の事前定義/カスタムロールを最小権限で委任するもの。OU は階層でポリシーを継承・出し分けする単位。
- グループ化と集計(変換)
- キーごとにまとめて合計・件数・平均などを求める変換。ゴールド層の作成やレポート用データの準備で使う。
- グレースフルデグラデーション(段階的縮退)
- 一部が落ちても全体停止せず、機能を絞って動かし続ける設計。キャッシュ済みデータの返却、非必須機能の停止、デフォルト応答などで、ユーザー影響を最小化する。
- グローバルユニキャストアドレス
- IPv6においてインターネット上で一意にルーティング可能なアドレス。先頭が2000::/3の範囲に属し、IPv4のグローバルアドレスに相当する。リンクローカルアドレスとは異なりルータを越えて到達可能であり、SLAACやDHCPv6で自動設定される。
- クロスアカウントアクセス
- あるアカウントのプリンシパルが別アカウントのロールを AssumeRole して行うアクセス。信頼ポリシーで許可し、第三者には ExternalId を使って混乱した代理(confused deputy)を防ぐ。
- クロスコンパイラ
- 開発を行うホスト環境(PC等)とは異なるアーキテクチャ・OSのターゲット機器向けに、実行可能なバイナリを生成するコンパイラ。組込みターゲットは自身の上で開発ツールを動かす計算資源やストレージを持たないことが多いため、高性能なホストPC上でクロスコンパイルし、生成物をターゲットへ転送・書込みする開発形態が一般的。
- クロスサイトスクリプティング(XSS)
- 脆弱なWebサイトに悪意あるスクリプトを埋め込み、閲覧者のブラウザ上でそれを実行させる攻撃手法。Cookie窃取や画面偽装などにつながる。出力時のエスケープ処理(サニタイズ)が基本的な対策。
- クロスサイトリクエストフォージェリ(CSRF)
- 利用者が正規サイトにログイン中の状態を悪用し、罠サイト経由で利用者の意図しないリクエスト(送金・投稿等)を正規サイトへ送らせる攻撃手法。ワンタイムトークンの検証などで防止する。
- クロススタック参照(Export/ImportValue)
- あるスタックの出力(Outputs)を Export し、別スタックが ImportValue で参照して値を共有する仕組み。VPC ID などを複数スタックで使い回す。密結合になりやすく、ネストスタックや SSM パラメータ参照が代替。
- クロスゾーン負荷分散
- 各ノードが全 AZ のターゲットへ均等に振り分ける設定。無効だと AZ ごとの台数差で偏りが出る。ALB は既定で有効(無料)、NLB は既定で無効(有効化は AZ 間転送課金あり)。
- クロスフィルター方向
- リレーションシップでフィルターが伝わる向き。既定は単一(ディメンション→ファクトの一方向)で安全、双方向は曖昧さ/循環のリスクがあり必要時のみ使う。
- クロスリージョン Load Balancer
- 複数リージョンの Load Balancer を 1 つのグローバル IP の背後に束ねる構成。地理的冗長と低遅延ルーティングを提供する。
- ゲームデー
- 意図的に障害を注入し、実際のインシデント対応をチームで演習するイベント。AWS の Fault Injection Service(FIS)を使ってインスタンス停止やネットワーク遮断などのカオス実験を安全に自動化し、運用手順やアラートの実効性を検証する。
- ゲストアクセス
- 組織外のユーザーを Teams や SharePoint に招待して共同作業させる機能。B2B コラボレーション(Entra External ID)で外部 ID を扱う。
- コアコンピタンス
- 他社が容易に模倣できない、企業の中核となる独自の強み(技術力・ノウハウなど)。特定の製品や事業に固有のものではなく、複数の事業領域に展開・応用できる点が特徴で、これを軸に事業ドメインを定義し競争優位を持続する経営戦略の考え方。
- コードサイニング(コード署名)
- ソフトウェアやインストーラにデジタル署名を施し、配布元の真正性と配布後に改ざんされていない完全性を利用者が検証できるようにする仕組み。署名者の秘密鍵でハッシュ値を署名し、利用者は署名者の公開鍵(証明書)で検証する。
- コードレビュー(Pull Request)
- Pull Request 上で差分にコメントし、変更を承認/変更要求するプロセス。必須レビュー数や CODEOWNERS による必須レビュアー指定でマージ前の品質を担保する。
- コーポレートガバナンス(企業統治)
- 企業経営が株主をはじめとするステークホルダーの利益に沿って適切に行われるよう、経営者を規律づけ監督する仕組み。取締役会・監査役・社外取締役による経営の監督、情報開示、内部統制の整備などを通じて、経営の透明性・健全性・説明責任を確保する。ITストラテジストは、IT戦略やIT投資が経営の監督・説明責任の枠組みに沿うよう、ITガバナンスをコーポレートガバナンスと整合させる立場にある。
- コールドスタンバイ / クロスリージョン DR
- AWS の標準的な DR は 4 段階=バックアップ&リストア/パイロットライト/ウォームスタンバイ/マルチサイト(アクティブ-アクティブ)で、RTO/RPO とコストのトレードオフで選ぶ。コールドスタンバイはバックアップ&リストアに近い最小構成の通称。クロスリージョン DR は AMI/スナップショット/データのリージョン間コピーと IaC で別リージョンへ復旧する。
- ゴールド層
- メダリオンの最終層。集計やビジネスロジックを適用し、レポート/分析がそのまま使えるデータ(多くは次元モデル)にする。
- コストガバナンス
- クラウド費用を組織的に統制する運用。予算(Budgets)と異常検知でアラート、コスト配分タグとカテゴリで可視化、SCP/Service Quotas で過剰リソースを抑制、購入オプション(RI/SP/Spot)で最適化。FinOps の実践基盤。
- コストと使用状況レポート(CUR)
- AWS が提供する最も詳細な請求データのレポート。時間単位の使用量・料金・割引適用の内訳などを CSV/Parquet 形式で S3 に出力し、Athena や QuickSight と連携した高度な分析・チャージバックの基礎データとして使う。
- コストベースライン
- 時間軸に沿って承認されたプロジェクト予算(フェーズ別・期間別の累積コスト)。マネジメント予備は含まないが、コンティンジェンシ予備は含む。EVMのPV(出来高計画値)はこのベースラインから導出され、実績との比較基準となる点で重要。
- コスト異常検知(Cost Anomaly Detection)
- 機械学習で普段の利用パターンを学習し、想定外のコスト急増を自動検知してアラート通知するサービス。予算超過の事後通知より早く異常を捉える。
- コスト効率指数(CPI)
- EVMでコストの遂行状況を評価する指標。CPI=EV(出来高)÷AC(実コスト)で算出し、1.0が予算どおり、1未満はコスト超過(非効率)、1超は予算より効率的に進んでいることを示す。
- コスト配分(チャージバック/ショーバック)
- クラウド費用を部門/プロジェクトに割り当てる運用。チャージバック=実費を各部門に請求(責任明確化)。ショーバック=請求せず使用量を可視化(意識づけ)。コスト配分タグ・コストカテゴリ・Cost Explorer で実現する。
- コネクションドレイン
- ロードバランサのバックエンドを外す際、新規接続を止めつつ既存接続を完了させてから切り離す仕組み。メンテナンスを無停止で行える。即時遮断ではない点に注意。
- コネクションプール
- データベース接続を再利用して、接続の確立コストや接続枯渇を防ぐ仕組み。サーバーレス/高並行のアプリで特に重要。
- コネクション追跡
- ステートフルなファイアウォール(例:セキュリティグループ)が確立済みの接続を状態テーブルで記憶し、その戻り通信を自動的に許可する仕組み。ステートレスなルールと違い、戻り方向のエフェメラルポートを個別に開ける必要がない。
- コネクタ(Power Platform)
- 1000以上の外部サービス(Microsoft 365・SQL・各種 SaaS)に接続する部品。標準コネクタと、追加ライセンスが要る場合のあるプレミアムコネクタがある。
- コネクタ(RJ-45/RJ-11)
- ケーブルを機器に接続するコネクタ規格。RJ-45は8本の心線を持つツイストペアケーブル用のコネクタでイーサネットの標準、RJ-11は電話線(アナログ回線)用の4〜6心のコネクタで、見た目は似ているがRJ-45より小さい。
- コピーレフトとパーミッシブ
- OSS ライセンスの2系統。コピーレフトは改変再配布時に派生物も同じライセンス(ソース公開)を求める伝播条件。パーミッシブは著作権表示を残せば改変版をクローズドにしてよい。義務が生じるトリガーは原則「再配布」。
- コピーレフト系ライセンス(GPL/AGPL/LGPL)
- コピーレフト系ライセンス。GPL は最も代表的でリンクした全体に公開義務が及ぶ。AGPL はネットワーク越しの提供(SaaS)にも公開義務を拡大。LGPL はライブラリ向けの緩和版で、リンクするだけなら伝播しない。
- コマンドインジェクション
- Webアプリの入力欄経由で、意図しないOSコマンドをサーバー上で実行させてしまう攻撃手法。入力値をそのままシェルコマンドの一部として渡してしまう実装が原因で、入力値の検証や、シェルを介さないAPI呼び出しへの置き換えで防止する。同種の攻撃であるSQLインジェクションやクロスサイトスクリプティング(XSS)と並び、入力値のサニタイズ不足が根本原因となる。
- コマンドジョブ
- 単一のスクリプトを指定の環境・計算・入力で実行する基本のジョブ。パラメーターやデータ入力を渡し、ログで障害を診断する。
- コマンドの所在確認(which/whereis/type)
- コマンドの所在を調べる3種。which は PATH 上の実行ファイルの場所、whereis は実行ファイル+マニュアル+ソース、type はエイリアスやシェルビルトインかどうかまで判定する(type cd → shell builtin)。
- コマンド置換
- コマンドの出力をその場に埋め込む記法。$(コマンド) または `コマンド`(バッククォート)で、FILES=$(ls *.log) のように結果を変数に取り込む。
- コマンド履歴(history)
- 過去に実行したコマンドの記録。history で一覧、!番号 で再実行、!! で直前を再実行。ログアウト時に ~/.bash_history へ保存される。
- コミット
- ある時点の変更のスナップショット。内容から計算される一意のハッシュ(SHA)で識別される。
- コミュニケーション コンプライアンス
- Microsoft Purview コミュニケーション コンプライアンスは、メールやチャットの不適切な表現・規則違反を検知してポリシー違反として通知する。
- コモンクライテリア(ISO/IEC 15408)
- IT製品のセキュリティ機能を評価するための国際標準規格で、評価保証レベル(EAL)で評価の厳格さを表す。日本ではこの規格に基づく第三者認証制度としてJISECが運用され、ICカード等の耐タンパ性を含むセキュリティ機能を客観的に評価・認証できる。
- コラボレーションアプリ(Loop/Whiteboard/Forms/Planner 等)
- Microsoft 365 の共同作業アプリ群。Loop(共有コンポーネント)・Whiteboard(共同ホワイトボード)・Forms(アンケート)・Planner/To Do(タスク)・Bookings(予約)・Stream(動画)などが連携する。
- コリジョンドメイン
- 複数の端末が同時に送信すると信号が衝突しうる範囲を指し、ハブやリピータで接続されたセグメント全体が1つのコリジョンドメインとなる。L2スイッチは各ポートを個別のコリジョンドメインに分離し、全二重接続では衝突自体が発生しないため実質的に消滅する。ブロードキャストドメインとは対照的に、スイッチのポート単位で分割される点が試験の頻出ポイント。
- コンソール/端末エミュレータ
- 文字ベースでシェルを操作する画面。物理的なテキストコンソールや、デスクトップ上でその機能を提供する端末エミュレータ(ターミナル)を通じてコマンドを入力する。
- コンソールポート
- ルーターやスイッチに直接ケーブル(コンソールケーブル)を挿して、ターミナルエミュレータからCLIにアクセスするための専用ポート。ネットワーク経由の接続ができない初期設定時や障害時に使う帯域外(out-of-band)管理手段。
- コンティンジェンシ計画
- あらかじめ定めたリスクの発生を示すトリガー条件が満たされたときに実行する対応計画。リスクが顕在化してから場当たり的に対応するのではなく、事前に計画しておくことで迅速かつ一貫した対応を可能にする点が重要。
- コンティンジェンシ予備
- 識別済みのリスク(「既知の未知」=known unknowns)に備えてコストベースラインに含めて確保する予備費。リスク分析(期待金額など)に基づき算定し、プロジェクトマネージャの裁量で使用できる。未識別のリスク(「未知の未知」)に備え経営層が管理するマネジメント予備とは区別される。
- コンテインドユーザー
- サーバーレベルのログインに依存せず、データベース自身にパスワードや Entra ID を紐づけて認証できるユーザー。Azure SQL Database では標準の運用パターンで、フェイルオーバーグループでのセカンダリへの昇格時もサーバー側の再作成が不要になる利点がある。
- コンテキスト(contexts)
- ランタイムのメタデータにアクセスするオブジェクト群。github・env・vars・secrets・inputs・matrix・needs・runner・job・steps などがある。
- コンテキストアウェアアクセス
- デバイスの状態・場所/国・IP 範囲・企業デバイスかどうかなどの条件に応じてアクセスを許可/制限するゼロトラスト的な制御。認証強化(2SV/SSO)とは別レイヤーで組み合わせて使う。
- コンテキストウィンドウの最適化
- モデルのコンテキストウィンドウ(有限のトークン上限)を効率よく使うための設計。RAGでは関連度の高いチャンクだけを検索・投入し、会話履歴は要約や古い発言のトリミングで圧縮し、無関係な情報を渡さないことで応答品質とレイテンシ/コストを両立させる。
- コンテキストウィンドウ超過
- 入力+出力トークンがモデルのコンテキストウィンドウ上限を超える状態。挙動はモデル/API により異なり(入力の切り捨て・エラー返却・古い会話履歴の脱落など)、回答が途中で切れる/情報が欠落する原因になる。動的チャンキング・プロンプト設計・応答長制限で対処する。
- コンテキストスイッチの削減
- 未知の API やエラーの意味を Chat で尋ねることで、ブラウザやドキュメントへ移る切り替えを減らし、開発の流れを保つこと。
- コンテキストの収集とプロンプト構築
- カーソル周辺・開いているファイル・関連ファイルから関連性の高い情報を選び、モデルに渡すプロンプトを組み立てる入力処理。除外ファイルは対象外。
- コンテナ(Linux)
- ホスト OS のカーネルを共有し、名前空間でプロセスを隔離する軽量な実行環境。ゲスト OS を起動しないため高速・軽量だが、ホストと同系統の OS しか動かせない。
- コンテナー
- キャンバスアプリで複数のコントロールをまとめ、画面サイズに応じて自動配置する入れ物。レスポンシブなレイアウト作りに使う。
- コンテナイメージ
- アプリと依存関係をまとめた不変のパッケージ。Dockerfile からビルドし、レジストリ(ACR)に push して各サービスで実行する。
- コンテナファイルシステム
- コンテナ内から見えるファイルシステムで、元になるイメージのレイヤーを重ね合わせて構成される。イメージ自体は読み取り専用のレイヤーの集まりで、コンテナ実行時にその上へ書き込み可能なレイヤーが1枚追加される。
- コンテナ化
- アプリと依存関係を 1 つのイメージにまとめ、どこでも同じように動かす技術。VM より軽量・高速起動で、密度とポータビリティが高い。AWS では ECR(保管)+ECS/EKS(実行)+Fargate(サーバーレス実行)で運用する。
- コンテナ仮想化
- ホストOSのカーネルを複数のアプリケーション実行環境(コンテナ)で共有し、プロセスやファイルシステムを名前空間で隔離する軽量な仮想化方式。ゲストOSを持つハイパーバイザ型仮想化と比べ、起動が高速でオーバーヘッドが小さい一方、ホストOSのカーネルに依存するため異なるOS種別のカーネルは動かせない。Dockerが代表的な実装。
- コンテンツフィルターとブロックリスト
- Azure OpenAI / Content Safety のセーフティ機能。カテゴリ別の重大度しきい値でフィルターし、独自のブロックリストで禁止語を加える。
- コンテンツ除外
- 特定のファイルやリポジトリを Copilot の文脈・提案の対象から外す設定。機密や規約上 AI に渡せないコードを守る。管理者がリポ/組織レベルで設定し、対象では補完が出ない。
- コントロール(Power Apps)
- アプリ画面に置く UI 部品。ラベル・テキスト入力・ボタン・ドロップダウン・ギャラリー・フォームなどがあり、プロパティで見た目や動作を設定する。
- コントロールプレーンとデータプレーン
- コントロールプレーンは経路計算やポリシー決定など転送規則を作る制御機能を、データプレーンは決定された規則に従いパケットを実際に転送する機能を指す。SDNはこの両者を分離しコントロールプレーンを集中管理することで、ネットワーク全体の柔軟な制御を可能にする。
- コンパクション(小ファイル統合)
- 多数の小ファイルを少数の大きなファイルにまとめ、メタデータ負荷とスキャンのオーバーヘッドを下げて読み取り性能を改善する処理。
- コンピュータービジョン
- 画像/動画を解析し、物体・文字・顔などを認識・理解するAI分野(分類・物体検出・OCR・顔検出等)。
- コンピューティングインスタンス
- 個人の開発・ノートブック実行用のマネージド VM。停止してコストを節約でき、ターミナルや Jupyter を備える。
- コンピューティングクラスター
- 学習やバッチ推論をスケールさせるオートスケール計算。アイドル時 0 ノードに縮小でき、低優先度/Spot VM でコストを抑えられる。
- コンプライアンス
- 企業が法令・社内規程・業界の行動規範などを遵守する経営上の取り組み。情報セキュリティに限らず、労働関連法規や会計基準など幅広い規範の遵守を指し、違反は企業の信用・存続に直結するため経営リスクとして扱われる。
- コンプライアンス スコア
- Microsoft Purview コンプライアンス マネージャーが算出する、規制・標準への準拠度を示す指標。推奨改善アクションの実施で上がる。
- コンプライアンス ポリシー(デバイス準拠)
- デバイスが暗号化や最小 OS バージョンなどの要件を満たすかを準拠/非準拠で判定する(判定結果を Conditional Access が使ってアクセスを制御する。判定と制御は別レイヤー)。
- コンプライアンスプログラムと AWS Artifact
- AWS は ISO・SOC・PCI DSS・HIPAA・FedRAMP 等の第三者認証に準拠し、その監査レポートを AWS Artifact からオンデマンドで取得できる。準拠範囲は責任共有モデルで分担する。
- コンプライアンスマネージャーとスコア
- Microsoft Purview コンプライアンスマネージャーは、規制や標準への準拠状況を改善アクションとコンプライアンススコアで可視化し、リスク低減の優先順位付けを助ける。
- コンプライアンス報告
- 基準や規制への準拠状況を評価・報告すること。AWS Config(ルール準拠)、Audit Manager(証跡収集)、Security Hub(統合スコア)で継続的に可視化する。
- コンフリクトマネジメント
- チーム内の対立を、撤退/回避・鎮静/適応・妥協・強制/指示・協力/問題解決の5つの技法から状況に応じて選び解消する活動。協力/問題解決は双方が満足する解を目指す最も望ましい技法とされ、状況(緊急性・関係性)に応じた使い分けが重要。
- コンポーネント(Power Pages)
- ページに配置する部品。テキスト・画像・フォーム・リスト(Dataverse データの一覧)・iFrame などがあり、ドラッグ&ドロップで構成する。
- コンポーネント(再利用可能なステップ)
- 入力・出力・コード・環境をまとめた再利用可能な処理単位。パイプラインのステップとして組み合わせ、バージョン管理・共有できる。
- コンポーネント図
- UMLの構造図の一つで、システムを構成する物理的なソフトウェア部品(コンポーネント)と、それらが提供・要求するインタフェースおよび依存関係を表す。提供インタフェース(ボール)と要求インタフェース(ソケット)で部品間の結合を示し、再利用単位や配置単位の分割を検討できる。実行時のノード配置を表す配置図とは対象が異なる。
- コンポジットアクション
- 複数のステップ(run: や他アクションの uses:)を 1 つのアクションに束ねたもの。ワークフローの 1 ステップとして uses: で呼び出す。
- コンポジットモデル
- Import と DirectQuery(や Direct Lake)を 1 つのモデルに混在させる構成。テーブルごとにモードを選べ、デュアルモードで両用もできる。
- コンボボックス
- 検索しながら選べ、複数選択にも対応するコントロール。候補が多いときや複数選択が要るときにドロップダウンの代わりに使う。
- サーキットブレーカー
- 連続失敗する呼び出し先を一時的に遮断(オープン)し、無駄な再試行と連鎖障害を防ぐパターン。一定時間後に半開で試行し、回復したら閉じる。タイムアウト・リトライ・バックオフと組み合わせる。
- サードパーティ Vault 連携
- 外部のシークレット管理基盤(HashiCorp Vault 等)に OIDC などで接続し、認証情報を実行時に動的取得する方式。GitHub に長期保存しないため漏えい面を減らせる。
- サーバーレス vs プロビジョニング(Cosmos DB)
- スループットモデルの選択。サーバーレスは消費した RU だけ課金で断続的/低トラフィック向け。プロビジョニングは RU/s を確保し安定/高トラフィック向けで、手動とオートスケール(上限内で 10%〜100% 自動変動)がある。
- サーバーレス(FaaS)
- サーバー管理が不要で、イベント時だけコードを実行し実行分だけ課金する形態(例:AWS Lambda)。
- サーバーレスコンピューティング(Azure SQL)
- 使用に応じて計算を自動スケールし、非アクティブ時に自動一時停止して秒課金を止める Azure SQL の計算層。断続的なワークロードに向く。
- サービスアカウント(Service account)
- 人ではなくワークロード(VM/アプリ)が使う特別な ID。鍵の代わりにメタデータ経由の短命トークンや Workload Identity Federation で認証するのが安全。
- サービスエンドポイント
- サブネットから PaaS への通信を Azure バックボーン経由にし、PaaS 側のファイアウォールで当該サブネットを許可する仕組み。プライベート IP は付与しない(オンプレからは不可)。サービスエンドポイントポリシーで宛先を制限できる。
- サービスカタログ
- 現在提供中のサービスを一覧化した文書で、サービスポートフォリオのうち稼働中の部分に相当する。利用者向けに内容や依頼方法を示す業務ビューと、支える構成要素を示す技術ビューの二面をもつことが多い。サービスマネージャはカタログを最新に保つことで、利用者への提示内容と社内の運用実態を一致させ、要求受付や責任範囲の明確化に用いる。
- サービスコンテナ(services:)
- ジョブ実行中だけ補助コンテナ(DB・キュー等)を起動する仕組み。ポートマッピングとヘルスチェックを設定でき、外部 DB なしで統合テストを再現できる。
- サービスコントロールポリシー(SCP)
- AWS Organizations でアカウントや OU に適用する組織的なガードレール。許可の上限を定め、メンバーアカウントの IAM がそれを超える権限を持てないようにする(許可の最大境界)。
- サービスチェイニング(NVA 経由)
- UDR の次ホップを NVA(ネットワーク仮想アプライアンス=ファイアウォール等)にして通信を必ず経由させる設計。NVA 側で IP 転送を有効化し、冗長化は内部 Load Balancer を前段に置く。
- サービスデスク
- 利用者からの問い合わせ・障害報告を受け付ける単一の窓口(シングルポイントオブコンタクト)。利用者が複数の連絡先を使い分ける必要をなくし、対応の一元管理を可能にする。
- サービスデスクとSPOC(単一窓口)
- サービスデスクは利用者とサービス提供者をつなぐ単一の連絡窓口(SPOC)として機能し、問い合わせや障害連絡を一元的に受け付ける。窓口を一つに集約することでたらい回しを防ぎ、記録・状況把握・オーナーシップを一元管理して対応品質と利用者満足を高める。
- サービスデスクの体制(ローカル/中央/バーチャル/フォロー・ザ・サン)
- サービスデスクの配置形態。利用者拠点ごとに置くローカル、拠点を一箇所に集約する中央、物理的な場所を問わず論理的に統合するバーチャル、時差のある複数拠点を引き継いで24時間対応するフォロー・ザ・サンがある。コスト、対応時間、言語や現地事情への適合性を踏まえて選択する。
- サービスにリンクされたロール
- AWS サービスが自分に代わって他リソースを操作するための、サービス専用に定義済みの IAM ロール。権限が事前定義され、誤って壊さない仕組みになっている(例:Auto Scaling・ELB・Config が利用)。通常のロールと違い削除・編集が制限される。
- サービスの計画(サービスマネジメントの計画)
- サービスマネジメントを効果的に運営するために、方針・目的・提供範囲・必要資源・役割責任・スケジュールをあらかじめ定める活動。JIS Q 20000のPDCAではPlanに相当し、以降の運用・監視・改善の土台となる。サービスマネージャは事業目標や顧客要求を計画に落とし込み、限られた資源をどのサービスにどう配分するかを決め、後続のプロセスが整合して動く前提を整える。
- サービスの測定・評価と監査
- サービスの品質や目標達成度をKPIやメトリクスによって測定し、その結果を評価したうえで、内部監査・外部監査により手順やコントロールの適合性を確かめ、逸脱に対して是正処置を講じる一連の統制活動。測定はSLAやサービス目標に紐づけ、事実に基づく改善の根拠とする。ITサービスマネージャは測定指標を目的に合わせて設計し、監査で明らかになった不適合の根本原因を分析して、再発を防ぐ是正と継続的改善につなげる判断を行う。
- サービスバリューシステム(SVS)
- ITIL4の中核概念で、需要と機会を入力として価値を出力する組織全体の仕組み。中心にサービスバリューチェーンを置き、その周囲を7つの指針原則・ガバナンス・継続的改善・プラクティスが取り囲む。サービスマネージャは個々の活動を局所最適するのではなく、需要から価値創出までの全体像をSVSとして俯瞰し、部分間の整合をとって運営を判断する。
- サービスバリューチェーン(SVC)
- SVSの中核をなす一連の相互接続した活動で、計画・改善・エンゲージ・設計及び移行・取得及び構築・提供及びサポートの6活動から成る。個々の需要ごとにこれらの活動を柔軟に組み替えてバリューストリームを形成し、価値を生み出す。サービスマネージャは対象サービスの要求に応じてどの活動をどう連結するかを設計し、無駄のない価値提供の流れを組み立てる。
- サービスメッシュ
- マイクロサービス間の通信を、各サービスに付随するサイドカープロキシ層で横断的に制御する基盤。アプリ本体のコードを変えずにトラフィック管理・リトライ・可観測性(分散トレーシング)・相互TLSなどのセキュリティを一元的に適用できる。サービス数が増えて通信の共通制御が煩雑になる局面で、アーキテクトが導入を検討する。
- サービスモデル(IaaS/PaaS/SaaS)
- クラウドの提供形態の分類。IaaS=仮想マシン等の基盤、PaaS=開発実行基盤、SaaS=完成アプリ(Microsoft 365 は SaaS)。上位ほど運用範囲が事業者側。
- サービスライフサイクル
- サービスが企画されてから廃止されるまでの一連の段階で、計画・設計・移行・運用・改善へと進む流れを指す。各段階の成果物が次段階の入力となり、運用で得た知見が改善を通じて次の計画へ還元される循環構造をもつ。サービスマネージャはサービスが現在どの段階にあるかを踏まえ、段階に応じた管理活動と次段階への引継ぎを判断する。
- サービスレベルと購入モデル(GP/BC/Hyperscale・vCore/DTU)
- Azure SQL の性能/可用性/コストを決める設定。サービスレベル=General Purpose(バランス型・リモートストレージ)/Business Critical(ローカル SSD・組み込みレプリカ・低遅延・読み取りスケールアウト)/Hyperscale(最大100TB級・ページサーバーでストレージ分離・高速バックアップ/復元)。購入モデル=vCore(柔軟・Azure Hybrid Benefit・予約割引が効く・推奨)/DTU(簡易指標)。計算は確定的(プロビジョンド)と、断続ワークロードで自動一時停止/再開するサーバーレス。多数 DB の容量共有はエラスティックプール。読み取りスケールアウトは BC/Hyperscale。
- サービスレベル管理(SLM)
- SLA(サービスレベル合意)の策定・監視・レビュー・改善を継続的に回すプロセス。合意したサービスレベル目標に対する達成状況を測定し、未達や変化があればレビューを通じて是正や再交渉につなげる。サービスマネージャはSLMを通じて顧客期待と提供能力の均衡を保ち、OLAやUCといった裏側の合意がSLA目標を支えられているかを点検する。
- サービスレベル目標(SLO)
- SLAの中で顧客と合意する、測定可能なサービスレベルの目標値。可用性や応答時間、復旧時間などを具体的な数値やしきい値として定め、達成状況を客観的に判定できるようにする。サービスマネージャは実現可能かつ顧客価値に見合うSLOを設定し、監視で達成度を測り、未達傾向があれば改善や合意見直しの判断材料とする。
- サービス資産管理(SACM)
- SACM(サービス資産管理及び構成管理)は、サービス提供に用いるサービス資産と、その構成情報を一体で管理する活動である。資産の識別・管理と、構成品目(CI)およびCI間の相互関係の管理を統合し、変更・リリースの影響分析や統制の基盤とする。ITサービスマネージャは資産と構成の記録を単一の正として維持し、実態との乖離を防ぐプロセスを設計することで、意思決定が信頼できる情報に基づくよう担保する。
- サービス正常性
- 管理センターで稼働状況・障害・予定メンテナンス・告知をリアルタイムに確認できる機能(「約束」のSLAに対し「現状」を示す)。
- サービス正常性(Service Health)
- Microsoft 365 admin center で Microsoft 側のサービス インシデント/アドバイザリ(停止・劣化・計画メンテ)を表示し通知を構成する機能。自社ネットワーク経路を評価する Network connectivity insights とは別。
- サービス接続
- Azure Pipelines から外部リソース(Azure サブスクリプション、コンテナーレジストリ、Kubernetes クラスター等)へアクセスするための認可設定。プロジェクト単位で作成し、パイプラインはサービス接続名を指定するだけで対象へ認証できる。承認とチェックでどのパイプラインが使えるかを制御できる。
- サービス報告(サービスレベル報告)
- サービスレベルの達成状況や傾向を、顧客や関係者へ定期的に報告する活動。SLOに対する実績、インシデントや変更の件数、改善の進捗などをまとめ、合意した頻度と様式で提示する。サービスマネージャは報告を通じて透明性を確保し、未達の説明責任を果たすとともに、次のレビューや改善につながる合意形成の場として活用する。
- サイドカーパターン
- メインのコンテナに補助コンテナ(ログ収集・プロキシ・セキュリティ)を同じタスク/Pod に並走させる構成。アプリ本体を変えずに横断的関心事を追加できる。サービスメッシュ(Envoy プロキシ)が代表例。
- サイドチャネル攻撃
- 暗号処理そのものの理論的弱点ではなく、処理時間・消費電力・電磁波・音などの物理的な副次情報(サイドチャネル)を観測して鍵などの秘密を推定する攻撃。耐タンパ性を高めた実装で副次情報の漏えいを抑える。
- サイト間 VPN(S2S)
- オンプレ拠点と Azure VNet を IPsec トンネルで常時接続する方式。VPN ゲートウェイとオンプレのローカルネットワークゲートウェイを構成する。
- サイト間VPNとリモートアクセスVPN
- サイト間VPNは拠点のVPNゲートウェイ同士を常時接続し拠点内の全端末が透過的に利用するのに対し、リモートアクセスVPNは個々の端末にクライアントソフトを導入し個人単位で社内網へ接続する。前者は拠点間通信、後者はテレワーク等の個別アクセスに適する。
- サイト信頼性エンジニアリング(SRE)
- ソフトウェアの考え方で運用を行い、信頼性を SLO(サービスレベル目標)やエラーバジェットといった測定可能な目標で管理する Google 発の手法。
- サイバーキルチェーン
- 標的型攻撃の一連の流れを「偵察→武器化→配送→攻撃→インストール→遠隔操作(C&C)→目的の実行」の段階に分けて整理するモデル。各段階で有効な防御策を検討し、どこで攻撃を断ち切れるかを分析するために用いられる。
- サイバーセキュリティ基本法
- 国のサイバーセキュリティ戦略の基本理念を定め、国・地方公共団体・重要インフラ事業者等の責務を明らかにする法律。内閣サイバーセキュリティセンター(NISC)の設置根拠となっており、国全体のサイバーセキュリティ政策の土台をなす。
- サイバーセキュリティ経営ガイドライン
- 経済産業省とIPAが策定した、経営者がリーダーシップを発揮してサイバーセキュリティ対策を推進するための指針。経営者が認識すべき3原則と、CISO等の責任者に指示すべき重要10項目から構成され、セキュリティ投資を経営課題として位置づける考え方を示す。
- サイレントソース検出と SOC メトリクス
- サイレントソース検出は、想定どおりにログを送らなくなった(沈黙した)ログソースを検知し、検出の盲点を防ぐ。SOC の運用品質は MTTD(平均検知時間)等の KPI で測り、しきい値アラートと通知(Cloud Monitoring)で基盤のヘルスを監視する。
- サイロ化
- 部門・業務システムごとにデータや業務プロセスが分断され、組織全体で情報共有・連携ができなくなっている状態。個別最適が進んだ結果として起こりやすく、全社横断のデータ活用やDX推進の障害となる。
- サブスクリプション(Azure)
- 課金と利用の境界であり、リソースの論理的な入れ物。部門や環境ごとに分けることが多い。
- サブスクリプション(シート)管理
- Copilot のシート割り当て・解除・利用状況取得の管理。UI のほか REST API から自動化でき、入退社に応じたシート運用に使う。
- サブスクリプションモデル
- 商品やサービスの所有権を一括で売り切るのではなく、一定期間の利用権に対して定期的に対価を受け取る収益モデル。利用実績データを継続的に得られるため顧客ニーズの変化を捉えやすく、解約率(チャーンレート)や顧客生涯価値(LTV)の管理が事業の成否を左右する。ITストラテジストは売り切り型からの転換によって収益の安定化と顧客との継続的な関係構築を狙う。
- サブネット
- 仮想ネットワークのアドレス空間を区切った小さなネットワーク範囲。用途や公開/非公開でリソースをグループ化し、ルーティングやアクセス制御の単位にする。
- サブネットの予約アドレス
- VPCの各サブネットで、ネットワークアドレス・VPCルーター用・DNS用・将来予約の最初の4つと、ブロードキャスト用(実際は未使用)の最後の1つ、計5アドレスをAWSが予約し割り当てできないようにする仕様。/24サブネットなら256個中251個が利用可能アドレスになる。
- サブネットマスク
- IP アドレスのうちネットワーク部とホスト部の境界を示す値(例 255.255.255.0)。CIDR のプレフィックス長と表裏一体の表現で、オンプレのネットワーク機器や一部のクラウド設定ではこのドット区切り表記が使われる。
- サブネット委任
- 特定の PaaS サービスにサブネットの管理権限を委ねる設定。サービスが必要なネットワーク構成(NIC 注入等)を自動適用できるようにする。
- サブボリューム(subvolume)
- Btrfs ファイルシステム内に作れる、独立してマウントやスナップショットの対象にできる論理的な区画。1つの Btrfs ファイルシステムを複数のサブボリュームに分け、それぞれ個別にスナップショットを取得できる。
- サプライチェーンセキュリティ
- ソフトウェアのサプライチェーン(依存パッケージや成果物)を保護する上位概念。GitHub では依存関係グラフ、Dependabot(脆弱性アラート・更新)、Dependency Review、SBOM 出力などを含み、直接依存だけでなく推移的依存も対象とする。
- サプライチェーン管理(セキュリティ観点)
- 製品・サービスの供給網全体(部材の調達元、利用するソフトウェア/OSSライブラリ、再委託先まで)を可視化し、各段階のセキュリティリスクを評価・管理する取り組み。近年はソフトウェア部品表(SBOM)の整備が有効な手段として注目されている。
- サプライチェーン攻撃
- 標的組織そのものではなく、セキュリティ対策が手薄な取引先・委託先・利用しているソフトウェア/ライブラリの供給元を踏み台にして侵入する攻撃手法。委託先経由の不正アクセスやソフトウェア更新プログラムへのマルウェア混入などが代表例。委託先のセキュリティ水準を契約・監査で担保することが対策になる。
- サポートとサービス要求
- Microsoft 365 管理センターからサービス要求(サポートチケット)を起票する。Unified/Premier などのサポートプランで応答時間や対象が異なる。
- サポートバンドル / 診断
- GHES が生成する診断情報の一式。GitHub Support 案件(障害・不具合・システム障害)の調査のために提供する。
- サロゲートキー
- システムが生成する整数の代理キー。業務キーと分離してディメンションの主キーにし、結合の安定や履歴管理(SCD)を容易にする。
- サンドボックス(マルウェア検証)
- メール添付ファイルなど未知の実行ファイルを、本番環境から隔離された仮想環境(サンドボックス)内で実際に動作させ、不審な挙動を示さないか安全に検証する仕組み。パターンマッチング検知をすり抜けるマルウェアでも、実行前に無害な環境で挙動を確認できる点が価値だが、近年はサンドボックス内での実行を検知して活動を偽装するサンドボックス回避型マルウェアへの対応も課題となっている。
- サンドボックス環境(Sandbox)
- 開発・テスト用の非本番環境。リセットやコピーができ、本番に影響を与えずに試せる。
- サンプリング(統計的・非統計的、試査と精査)
- 母集団の一部を抽出して監査証拠を入手する試査の手法。統計的サンプリングは確率理論に基づき客観的な基準で標本を抽出し結果を母集団に一般化できるのに対し、非統計的サンプリングは監査人の経験・判断に基づいて抽出する。母集団の一部のみを調べる試査に対し、母集団全件を調べる精査があり、リスクの大きさや汎用監査ソフトウェアの利用可否に応じて使い分ける。
- サンプリング方法(グリッド/ランダム/ベイズ)
- スイープで探索空間から構成を選ぶ方式。グリッド(全数)・ランダム(無作為・広く速い)・ベイズ(過去結果から有望領域を学習)。
- シークレットのスコープ(環境>リポ>組織)
- シークレットは組織・リポジトリ・環境(environment)でスコープを持ち、同名は狭いスコープが優先(環境>リポ>組織)。組織シークレットは許可リポを限定し、共通認証情報は組織レベルで一元管理するとローテーションが容易。
- シーケンス
- 呼び出しごとに一意な連番を生成するデータベースオブジェクト。主キーの自動採番などに使われ、CREATE SEQUENCE で作成する。
- シーケンス図
- 複数のシステムやコンポーネント間でメッセージ(API呼び出し等)がどの順序でやり取りされるかを時系列で示す図。縦のライフラインが各主体を表し、横向きの矢印が呼び出しや応答を表す。API呼び出しを含む処理の流れを読み解いたり設計を伝えたりする際に使う。
- シェアリングエコノミー
- 個人や企業が保有する遊休資産(自動車・住居・スキル・モノなど)を、インターネット上のプラットフォームを介して他者と共有・貸借する経済の仕組み。所有せずに必要な時だけ利用する消費スタイルを広げ、資産保有者は稼働率の低い資産から収益を得られる。ITストラテジストは自社の遊休資産や余剰能力をマッチングサービス化できないか、新規事業の着想として検討する。
- ジェイルブレイク検出
- システムプロンプトの制約を回避させようとする入力(ジェイルブレイク)を検知・遮断する対策。分類器・パターン検知・Guardrails・敵対的テスト(レッドチーミング)を組み合わせる。プロンプトインジェクションと並ぶ生成 AI の主要リスク。
- シェル(bash)
- ユーザーが入力したコマンドを解釈してカーネルに渡す対話環境。Linux の標準は bash。変数・引用符・履歴・パス解決といった動作原理がスクリプトやテキスト処理の土台になる。
- シェルスクリプトとシバン
- 一連のコマンドをファイルにまとめて自動化する。先頭行のシバン #!/bin/bash が解釈するインタプリタを指定し、chmod +x で実行権を付けて ./script.sh で実行する。
- シェル関数
- よく使う一連の処理に名前を付けて再利用する部品。name() { … } または function name { … } で定義し、関数内の $1 は関数自身の引数を指す。
- シェル起動ファイル(ログイン/非ログインシェル)
- ログインシェル(ssh ログイン等)は /etc/profile → ~/.bash_profile・~/.bash_login・~/.profile の最初の1つだけを読む。非ログインシェル(端末の新規タブ等)は /etc/bash.bashrc → ~/.bashrc を読む。環境変数は profile 系、alias や関数は .bashrc に置くのが定石。ログアウト時は ~/.bash_logout。
- シェル変数と環境変数
- シェル変数は NAME=value(=の前後に空白なし)で定義し、そのシェル内でのみ有効。export すると環境変数になり子プロセスへ継承される。一覧は set(全部)/env(環境のみ)、削除は unset、表示は echo。
- シグナルとプロセス終了(kill/pkill/killall/pgrep)
- プロセスへ制御を伝える仕組みがシグナル。既定の SIGTERM(15)は穏当な終了要求、SIGKILL(9)は捕捉不可能な強制終了、SIGHUP(1)は端末切断/設定再読込。kill は PID 指定、pkill/killall は名前指定、pgrep は名前で PID を検索する。
- システムカタログ(pg_catalog)
- PostgreSQL 独自形式でメタデータを保持するスキーマ。テーブル・索引・型・関数・権限などサーバの全オブジェクト情報を格納し、system information functions(current_database() など)と組み合わせて内部状態を調べられる。
- システムクロックとハードウェアクロック(date/hwclock)
- Linux には OS が刻むシステムクロック(date/timedatectl)と、マザーボード上のハードウェアクロック(hwclock)の2つの時計がある。hwclock --systohc はシステム→ハードウェアへ書き込み、--hctosys は逆向き。
- システムの冗長構成(デュアル・デュプレックス)
- 故障に備えてシステムを二重化し、可用性を高める構成。デュアルシステムは同じ処理を2系統で同時に行い結果を照合するため信頼性が高い。デュプレックスシステムは普段使う主系と、故障時に切り替える待機系(副系)に分けて備える構成で、待機系の準備の度合いによりホット/コールドスタンバイなどに分かれる。
- システムルート
- VNet 内・ピアリング・ゲートウェイ・既定インターネットへの経路を Azure が自動付与する既定ルート。UDR で上書きできる。
- システム化計画
- 共通フレーム(SLCP)の企画プロセスは「システム化構想の立案」と「システム化計画の立案」から成り、本用語は後者に当たる。経営戦略・業務課題を受けて、システム化の対象範囲・目的・投資対効果・開発体制・スケジュールを具体化し、次の要件定義プロセスへつなぐ、システム開発の最上流工程。
- システム化構想(システム化構想の立案)
- 共通フレーム(SLCP)の企画プロセスの最上流にあたる工程で、経営戦略・事業目標を踏まえ、対象とする業務・システム化の範囲や狙いを大づかみに描く段階。後続の「システム化計画の立案」がスコープ・体制・スケジュール・投資対効果を具体化するのに対し、システム化構想はその前提となる経営上のねらい・対象業務の方向性を経営層と合意する位置づけにある。ITストラテジストは、経営戦略と整合したシステム化構想を描き、経営層の承認を得たうえで具体的な計画へ落とし込む役割を担う。
- システム監査
- 情報システムが安全・効率的に運用されているかを、独立した立場の監査人が第三者の視点で検証・評価し、改善を助言する活動。監査対象部門から独立していることが信頼性の前提。
- システム監査の実施段階(予備調査・本調査・フォローアップ)
- システム監査の実施段階は、監査計画の後、まず予備調査で監査対象の体制やアクセス権限の管理方法など概況を把握する資料を収集し、続く本調査で実際のログや変更記録など具体的な証跡を抽出・検証して問題点を洗い出す。監査報告の後にはフォローアップとして、指摘した改善策が実際に実施されたかを後日確認する。
- システム監査の手順(計画・実施・報告・フォローアップ)
- システム監査は「監査計画→監査の実施→監査報告→フォローアップ」の順で進む。計画で目的・範囲を定め、実施で証拠を集めて評価し、報告書で問題点と改善提案を伝える。フォローアップでは、指摘した改善が実際に行われたかを後日確認する。
- システム監査基準
- 経済産業省が定める、システム監査人が監査業務を実施し報告する際のよりどころとなる行為規範。一般基準(監査人の要件・独立性等)、実施基準(監査計画・実施の手順)、報告基準(監査報告の作成・伝達)から構成され、監査の品質を担保する。監査人は自らの監査手続がこの基準に照らして適切かを常に検証する。
- システム管理基準
- 経済産業省が定める、情報システムの企画・開発・運用・保守を組織がどう管理すべきかを示す実践規範。監査対象(被監査部門)が遵守すべき望ましい管理の姿を示し、システム監査人はこれを監査の判断尺度として、実際の管理状況との差異を評価する。システム監査基準(監査人の行為規範)とは役割が異なる点に注意する。
- システム構成ツール(Ansible)
- 複数サーバーへの設定変更やソフトウェア導入を自動化・標準化するツール。対象ホストをインベントリで管理し、YAML で書いた Playbook をモジュール経由で実行する。エージェント不要で SSH 越しに動き、同じ Playbook を何度実行しても結果が変わらない冪等性を持つため、仮想サーバーやコンテナの払い出し、アプリのリリース、ネットワーク機器の設定変更まで一貫した手順で行える。
- システム停止・再起動コマンド(shutdown/reboot/halt/poweroff)
- システムを安全に停止・再起動するコマンド群。shutdown は時刻指定(-h 停止/-r 再起動)とログイン中ユーザーへの警告ができる正規の手段。halt は停止、reboot は再起動、poweroff は電源断。
- シスログとシスログ集約
- Syslogは機器のイベント・エラー等のログをUDP/TCP 514番等で標準化された形式(ファシリティ・重大度レベルを含む)で送信するプロトコル。多数の機器から出力されるログを1台のシスログサーバに集約(一元収集)することで、横断的な相関分析・障害の時系列突き合わせ・長期保存によるコンプライアンス対応が可能になる。UDP利用時は再送保証がなく、ログ欠落のリスクがある点に注意が必要。
- ジッタとジッタバッファ
- ジッタはパケット到着間隔のばらつき(遅延の揺らぎ)。平均遅延が許容範囲でもジッタが大きいと音声・映像が途切れる。受信側にジッタバッファ(ゆらぎ吸収バッファ)を設け、到着したパケットを一定時間バッファリングしてから一定間隔で再生することで、ばらつきを吸収し滑らかな再生を実現する。
- シフトレフト
- セキュリティを開発の早い段階へ前倒しして問題が大きくなる前に防ぐ考え方。Push Protection・依存スキャン・マージ前解析で早期予防する。後工程ほど修復コストが高くなる。予防は検出/修復を置き換えない(多層で)。
- ジャーナリング
- 書き込み操作を先に記録してから実行する仕組み。電源断などでもファイルシステムの整合性が壊れにくい。ext3/ext4/XFS が備える。
- ジャクソン法(JSP)
- 入力データ構造と出力データ構造を基準にプログラム構造を導くプログラム設計技法(Jackson Structured Programming)。データを順次・選択・繰返しの三つの基本構造でモデル化し、入出力のデータ構造からプログラムの制御構造を機械的に対応づけて設計する。データ構造が処理構造を規定するという考え方に立ち、システムアーキテクトが構造的な妥当性を保証しやすい点が特徴である。
- ジョブ outputs
- ステップ出力をジョブの outputs に割り当て、後続ジョブが needs.<job>.outputs.<name> で読めるようにする仕組み。別ジョブへ短い値を渡す。
- ジョブ(job)
- ワークフロー内の実行単位。runs-on でランナーを選び、ステップの列を実行する。既定で他ジョブと並列に動き、各ジョブは独立した環境で実行される。
- ジョブブックマーク
- 処理済みデータの位置を記憶し、再実行時に未処理分だけを増分処理して重複を防ぐ Glue の機能。
- ジョブ制御(bg/fg/jobs)
- シェルでコマンドをフォアグラウンド/バックグラウンドで動かす仕組み。末尾の & で背面起動、Ctrl+Z で一時停止、bg で背面再開、fg で前面へ、jobs で一覧。
- シルバー層
- メダリオンの中間層。クレンジング・重複排除・結合・型整備を行い、整合の取れた統合データにする。
- シンクライアント
- クライアント側に業務処理やデータをほとんど持たせず、実行結果の画面だけを転送してサーバに処理を集中させる方式。端末に情報が残らないため情報漏えい対策になり、ソフト更新やバックアップをサーバ側で一括管理できて運用が集約される。反面、サーバとネットワークへの依存が高まり、そこが単一障害点や性能要件の焦点になる。
- シングルサインオン(SSO)
- 一度のサインインで複数のアプリにアクセスできる仕組み。
- シングルユーザモード
- 通常のクライアント接続を受け付けず、ローカルから直接1接続のみでサーバを操作できる緊急復旧モード。破損したシステムカタログの修復や、通常起動できない状態からの応急処置に使う。postgres --single コマンドで起動し、単一のトランザクション内でシステムカタログの手動修正やVACUUMを行うのに用いる。
- スイープジョブ(ハイパーパラメーター調整)
- 探索空間・サンプリング・主要メトリック・早期終了を指定して多数の試行を走らせ、最良のハイパーパラメーター構成を見つけるジョブ。
- スーパースカラとアウトオブオーダー実行
- スーパースカラは複数の実行ユニットを持ち、1クロックで複数命令を並行発行してIPCを高める方式。アウトオブオーダー実行は依存関係のない後続命令をプログラム順を無視して先に実行し、パイプラインの空きを減らして高速化する技法。両者は現代CPUの高性能化の柱。
- スキーマ
- データベース内でテーブルや他のオブジェクトを論理的にグループ化する名前空間。search_path 設定で修飾なしのオブジェクト名を解決する際に検索するスキーマの順序を指定する。
- スキーマレジストリ
- ストリーム/メッセージのスキーマを集中管理し、互換性(後方/前方)を強制してプロデューサーとコンシューマーの破壊的変更を防ぐ仕組み。Glue Schema Registry が代表。
- スキャン種別(Seq Scan / Index Scan / Bitmap Scan)
- プランナが選ぶ主要なスキャン方式。Seq Scan はテーブル全体を順に走査する(対象行が多い/インデックスが使えない場合に有利)。Index Scan はインデックスを使い内側テーブルへ効率的にアクセスする。Bitmap Index Scan で複数条件の索引結果をビットマップに合成し、Bitmap Heap Scan がそのビットマップに基づきページ順でヒープへアクセスすることでランダムI/Oを減らす。
- スキルセットとカスタムスキル
- インデックス作成時に AI エンリッチメント(OCR・エンティティ抽出・翻訳等)を適用するスキルの集合。独自処理はカスタムスキルとして組み込む。
- スクリプトインジェクション
- PR タイトルや Issue 本文などの信頼できない入力を run: のシェルコマンドに直接埋め込むと、攻撃者のコマンドが実行される脆弱性。値を環境変数に入れて引用し、検証・最小権限・検証済みアクションで緩和する。
- スクリプトのデバッグ(bash -x)
- スクリプトが期待どおり動かないとき原因を調べる方法。bash -x は実行した各コマンドを変数展開後の形で表示(実行トレース)、bash -v は読み込んだ行をそのまま表示する。
- スケーラビリティ
- 需要に応じて能力を増減できること。スケールアップ=垂直(1台を大きく)、スケールアウト=水平(台数を増やす)。
- スケールアウト
- 処理能力を上げるためにサーバーの台数を増やす方式。1台あたりの性能を上げるスケールアップ(垂直スケーリング)と対比される水平スケーリングで、ロードバランサーの背後にステートレスなサーバーを並べる構成と相性がよい。
- スケールアップ・ダウン
- 個々のサーバーの性能(CPU・メモリ等)を増減させて処理能力を調整する方式。性能を上げるのがスケールアップ、下げるのがスケールダウン。台数を変えるスケールアウト・インとは対照的。
- スケールイン
- 負荷が下がった際にサーバーの台数を減らして無駄なコストを抑える方式。スケールアウトと対になる操作で、オートスケーリングではメトリクス(CPU使用率等)のしきい値を下回ると自動的にスケールインが実行される。
- スケールセットの自動スケール
- 仮想マシンスケールセットを CPU 等のメトリックやスケジュールに応じて自動でインスタンス数を増減する。スケールイン/アウトのルールと上限/下限を定義する。
- スケジュールクラウドフロー
- 定刻・定期(毎朝、毎週など)で自動実行するクラウドフロー。定例レポートや定期チェックに使う。
- スケジュールされたクエリ
- BigQuery で定期的に同じクエリ(集計など)を自動実行する手軽な機能。複雑な依存は Cloud Composer。
- スケジュールとイベントトリガー
- パイプラインの起動方法。スケジュールは定時起動、イベントベーストリガーはファイル到着などの出来事で起動する。
- スケジュール効率指数(SPI)
- EVM(アーンドバリューマネジメント)でスケジュールの遂行状況を評価する指標。SPI=EV(出来高)÷PV(計画価値)で算出し、1.0が計画どおり、1未満はスケジュール遅延、1超は計画より進んでいることを示す。
- スケジュール更新(Power BI)
- Import モデルを定期的に最新化する設定。オンプレ/VNet ソースにはオンプレミスデータゲートウェイが必要。
- スコアリングスクリプト(init/run)
- デプロイで推論を実装するスクリプト。init() でモデルを読み込み、run() で各リクエストを処理する。MLflow モデルでは不要なことがある。
- スコープクリープ
- 正式な変更管理プロセスを経ずに、なし崩し的にプロジェクトのスコープが拡大していく現象。追加のコスト・スケジュール影響が評価・承認されないまま作業が増えるため、統合変更管理を徹底し兆候を早期に検知して対処することが重要。
- スコープ記述書
- プロジェクトの成果物・境界・除外事項・受入基準を詳細に定義した文書。WBS作成の土台となり、何が含まれ何が含まれないかを関係者間で明確にすることでスコープクリープを防ぐ点で重要。
- スコープ検証(検収)
- 完成した成果物が要求事項を満たしているかを顧客・スポンサーと正式に確認し受け入れてもらうプロセス。品質管理(技術的な正しさの確認)とは異なり、成果物が合意した範囲を満たすかという受入れの観点である点が重要。
- スタースキーマ
- 中央のファクトテーブルの周りに、分析の切り口となるディメンションテーブルを放射状に配置した非正規化の設計。結合が少なく BI で高速。
- スターターワークフロー
- 新しいワークフローを作るときの雛形(テンプレート)。組織の .github リポジトリの workflow-templates に置き、メンバーが選んでコピーする。コピー後は独立し、元の更新は波及しない。
- スタック(LIFO)
- 最後に格納したデータを最初に取り出すデータ構造(LIFO:Last In First Out)。データの出し入れは一方の端(トップ)からのみ行う。ブラウザの「戻る」履歴などに例えられる。
- スタックとキュー(抽象データ構造)
- データの出し入れの順序に規則を持つ基本的なデータ構造。スタックは後入れ先出し(LIFO)、キューは先入れ先出し(FIFO)で要素を管理し、擬似言語プログラムの部品としてよく登場する。
- スタックポリシー
- スタック更新時に、特定リソースの更新/置換/削除を保護する JSON ポリシー。本番 DB などを意図しない更新から守る。IAM ポリシーとは別物。
- スタンバイ方式(ホット・ウォーム・コールド)
- 待機系(予備系)を主系の障害に備えてどの程度稼働させておくかの方式。ホットスタンバイは待機系を常時稼働・同期させ即時に切り替えられる(切替時間は最短だが機器と電力のコストが高い)、ウォームスタンバイは待機系を起動済みだがデータ同期など一部準備を要する中間形、コールドスタンバイは待機系を停止しておき障害時に起動するため切替に時間を要するがコストは最も低い。システムアーキテクトは要求される目標復旧時間(RTO)とコストの折り合いから方式を選定する。
- スティッキーラーニング(ポートセキュリティ)
- ポートセキュリティで、動的に学習したMACアドレスを実行コンフィグへ自動的に書き込み、以後は許可済みMACアドレスとして固定する設定モード。手動で1件ずつMACを打ち込む静的登録と、再起動のたびに学習し直す動的学習の中間に位置し、運用の手間を抑えつつ持続的な制御を得られる。
- ステークホルダエンゲージメント
- ステークホルダの現在の関与レベル(不認識・抵抗・中立・支持・主導)を把握し、目標とする関与レベルへ引き上げるための計画的な働きかけ。抵抗を示すステークホルダには特に重点的な関与戦略が必要と判断する根拠になる点で重要。
- ステージング(一時領域)
- 取り込んだデータを変換前に一旦置く中間領域。本番テーブルへ反映する前の検証・整形に使う。
- ステージングエリア(インデックス)
- 次のコミットに含める変更を選んで置く場所。git add で追加する。
- ステータスバッジ
- README に貼る SVG バッジで、特定ブランチ/イベントのワークフローの最新結果(成功/失敗)を一目で可視化する。
- ステータスライト
- ネットワーク機器のポートに付いたLED。点灯・点滅・消灯や色でリンクの状態(接続の有無・速度・通信中かどうか)を示し、障害の切り分けの最初の手がかりになる。
- ステートフルインスペクション
- 通過する通信のコネクション(セッション)状態をファイアウォールが動的に記憶し、内部から開始した通信に対応する戻りの応答パケットのみを自動的に許可する方式。単純パケットフィルタリングと異なり戻り通信ごとに静的ルールを書く必要がない。
- ステートレス
- 各リクエストやパケットを、それ以前の通信状態(コネクション情報・セッション情報)を保持・参照せず独立に処理する性質。ステートレスなパケットフィルタリングは各パケットのヘッダ情報のみで許可・拒否を判定するため高速・低負荷だが、ステートフルインスペクションのようなセッション文脈に基づく高度な制御はできない。負荷分散やスケールアウトの観点では、サーバ側の状態を持たないステートレス設計の方が任意のサーバへ自由に振り分けやすいという利点がある。
- ステップ(step)
- ジョブを構成する個々の処理。run: でシェルコマンドを、uses: でアクションを実行する。上から順に実行される。
- ストアドプロシージャ(Cosmos DB)
- Cosmos DB のサーバーサイド JavaScript で、同一論理パーティション内の複数項目をトランザクション(ACID)として処理する。実行時にパーティションキーを指定し、論理パーティションを跨げない。
- ストアドプロシージャ(Warehouse)
- ウェアハウスで一連の T-SQL 処理(複数ステートメント・制御フロー・パラメーター)をまとめて実行する再利用可能なオブジェクト。パイプラインのアクティビティから呼び出してデータ変換ロジックをオーケストレーションするのに使う。
- ストラングラーフィグパターン
- モノリスを安全に近代化する段階移行の手法。API Gateway や ALB をファサードに置き、機能を 1 つずつ新サービスへ切り出してルーティングを差し替え、最後に旧モノリスを廃止する。一括書き換え(ビッグバン)の高リスクを避ける。
- ストリーミング/ロジカルレプリケーションの基礎
- PostgreSQL のレプリケーション方式。ストリーミングレプリケーションは WAL をリアルタイムにスタンバイへ送信して物理的に同期する方式、ロジカルレプリケーションは変更を論理的な行の変更としてパブリッシュ/サブスクライブする方式。Silver では概念レベルの基礎知識が対象(構築・監視・障害対応は Gold の範囲)。
- ストリーミングエンジンの選択
- ノーコードで広く繋ぐなら Eventstream、複雑/大規模処理なら Spark 構造化ストリーミング、低遅延クエリ集計なら KQL、と用途で選ぶ。
- ストリーミングレプリケーションのエラーハンドリング
- walreceiver と walsender の接続が切れた場合の基本挙動は設定次第で自動再接続を試みること。ネットワーク断など一過性の要因なら再接続で復旧するが、スタンバイの遅延が wal_keep_size 等の保持範囲を超えてWALが欠落している場合は再接続だけでは復旧できず、ベースバックアップの取り直しが必要になる。
- ストリーミングレプリケーション構成パラメータ(wal_level/max_wal_senders/synchronous_standby_names/synchronous_commit/hot_standby_feedback)
- ストリーミングレプリケーションを構築する主要パラメータ。wal_level=replica 以上でレプリケーションに必要なWAL量を出力、max_wal_senders は同時に接続できるwalsender数の上限、synchronous_standby_names は同期レプリケーションの対象スタンバイ指定、synchronous_commit はコミット確定に必要な同期範囲、hot_standby_feedback はスタンバイの問い合わせがマスタ側のVACUUMを妨げないよう調整する。
- ストリーム処理
- イベントを到着順にほぼリアルタイムで処理する方式。低遅延が要る場面に。例:センサー警報。
- ストレージアカウントの種類と性能
- 汎用 v2(GPv2)が標準で Blob/File/Queue/Table を扱う。性能は Standard(HDD)と Premium(SSD・低遅延)から選び、Premium は BlockBlob/FileShare/Page 用に種別が分かれる。
- ストレージエンジン vs フォーミュラエンジン
- DAX 実行の 2 エンジン。ストレージエンジン(VertiPaq・並列・高速)とフォーミュラエンジン(単一スレッド・遅くなりがち)。後者偏重が遅さの原因になりやすい。
- ストレージのアクセス(アクセスキー/SAS)
- Azure ストレージへのアクセス手段。アクセスキー=アカウント全体のフルアクセス(要ローテーション)、SAS(共有アクセス署名)=対象/操作/期限を限定した委任(ユーザー委任SASが安全)、Entra ID + RBAC=キー不要の推奨方式。VNet 限定はプライベートエンドポイント/ファイアウォール。
- ストレージモード
- セマンティックモデルがデータをどう保持/取得するかの方式。Import・DirectQuery・Direct Lake があり、速度と鮮度のトレードオフで選ぶ。
- スナップショット(snapshot)
- ある時点でのファイルシステムやボリュームの状態を凍結して保持する仕組み。LVM のスナップショット LV や Btrfs のスナップショットが代表例で、変更差分だけを記録するため作成コストが小さく、バックアップや障害時のロールバックに使える。
- スノーフレークスキーマ
- ディメンションをさらに正規化して複数テーブルに分けた設計。結合が増え、スタースキーマより BI 性能が落ちやすい。
- スパイラルモデル
- 要求定義・設計・実装・評価のサイクルをリスク分析を挟みながら繰り返し、成果物の完成度を段階的に高めていく開発プロセスモデル。ウォーターフォールの硬直性と反復開発の柔軟性を組み合わせ、各周回でプロトタイプを作りリスクを低減してから次工程へ進む点が特徴。
- スパニングツリープロトコル(STP)
- L2ネットワークで冗長経路(ループ)が形成された際、ブリッジID(優先度+MACアドレス)が最小のスイッチをルートブリッジに選出し、冗長なポートを自動的にブロッキング状態にしてループとブロードキャストストームを防ぐプロトコル。収束を高速化したRSTPもある。
- スプリットブレイン
- ネットワーク分断や旧プライマリの誤った再起動などにより、新旧2つのプライマリが同時に書き込みを受け付けてしまう状態。データの整合性が崩壊するため絶対に避けるべき事故で、フェンシング(STONITH:問題ノードを強制隔離)で二重稼働を防ぎ、収束後は pg_rewind 等で旧プライマリをスタンバイへ正しく再統合する。
- スプリント
- スクラムにおける固定長(通常1〜4週間)のタイムボックスで、この期間内で計画・実装・レビュー・振り返りを一巡させ、リリース可能な成果物の増分を作る。期間は途中で延長せず、未完了項目は次のスプリントへ回すのが原則。
- スプリントレビューとスプリントレトロスペクティブ
- どちらもスプリント終了時に行うイベントだが目的が異なる。スプリントレビューは完成した成果物をステークホルダーに示しフィードバックを得て、次のプロダクトバックログを調整する場。スプリントレトロスペクティブは開発チーム自身がスプリントの進め方(プロセス・ツール・コミュニケーション)を振り返り、次のスプリントでの改善点を洗い出す場。「成果物への外部フィードバック」か「チーム内プロセス改善」かが判別の要点。
- スポット中断通知
- AWS がスポットインスタンスの容量を回収する約 2 分前に発行される通知。EventBridge のイベントやインスタンスメタデータ(instance-action)で受け取り、チェックポイント保存や後続タスクへの引き継ぎなど、中断前に安全に処理を終える猶予として使う。
- スマート工場(Industrie4.0)
- IoTセンサーやロボット、AIによるデータ分析を工場内の設備・工程に組み込み、生産状況をリアルタイムに把握・最適化する工場。ドイツ発の国家戦略「インダストリー4.0」が提唱する第4次産業革命の実現手段の一つで、個別受注品を大量生産と同等のコストで作る「マスカスタマイゼーション」も志向する。ITストラテジストは製造現場のデータを経営判断や需給予測に連動させ、生産性向上と多品種変動生産への対応を両立させる構想を描く。
- スムージングとバースティング
- 容量の使用を平準化する仕組み。バースティングで一時的に高い処理能力を使い、スムージングでその消費を一定時間に按分する。過負荷時はスロットリングが起きる。
- スラッシング
- 多重度が高すぎるなどの理由でページフォールトが頻発し、ページの読み書き(ページング)にCPU時間の大半が費やされて実処理の性能が著しく低下する現象。多重度の適正化やメモリ増設で対処する。
- スリープモード
- CPUのクロック供給や一部の周辺回路への電源供給を停止し、割込みなど特定のイベント発生まで低消費電力状態を維持する動作モード。ディープスリープほど消費電力は下がらないが復帰(ウェイクアップ)時間が短く、間欠動作でセンサ計測と待機を繰り返すIoT機器の電池寿命設計で使い分けが重要になる。
- スループット
- 単位時間当たりにシステムが処理できる仕事量を表す性能指標で、1秒当たりの処理件数(トランザクション/秒)やデータ転送量(バイト/秒)などで表す。同時処理数やハードウェア資源の増強、ボトルネックの解消によって向上する。システムアーキテクトはピーク時の要求スループットを見積もり、それを満たす構成と余裕(キャパシティ)を設計する。
- スループット最適化(生成 AI)
- 生成 AI の処理量を高める最適化。トークン処理の効率化、バッチ推論、同時実行数の管理、プロビジョンドスループット、キャッシュを組み合わせ、スロットリングを避けつつ単位時間の処理を最大化する。
- スレットハンティング
- アラートを待たず、インシデント/脅威インテリジェンス/ポスチャ/行動に基づく検証可能な仮説を立て、ログを横断(Logs Explorer/BigQuery/Google SecOps)して能動的に脅威を探す活動。
- スロットリング(容量)
- 容量を超過して使い続けたときに、処理が遅延/拒否される抑制。容量メトリックで原因を特定し、最適化やスケールで解消する。
- スロットリングと retry(指数バックオフ)
- API のリクエスト制限(throttling)で 429 が返るとき、指数バックオフの retry で対応する。
- スワップ
- 物理メモリが不足したときにデータを一時退避させるディスク領域。mkswap で初期化し、swapon で有効化(swapoff で解除)。パーティションを分割する定石の1つ。
- セカンダリ CIDR
- 既存の VPC に後から追加の CIDR ブロックを割り当て、利用可能な IP アドレス空間を拡張する機能。プライマリ CIDR と重複しない範囲を選ぶ必要があり、IP アドレス枯渇(サブネット追加の余地がない)への対処としてよく使われる。
- セキュアブート
- 起動時にブートローダやファームウェアのデジタル署名を検証し、正規の(改ざんされていない)ソフトウェアのみを実行させる仕組み。攻撃者が不正なファームウェアを書き込んでも起動を拒否できるため、OTA更新を行うIoT機器において、不正コード実行や乗っ取りを防ぐ組込みセキュリティの基盤機構となる。
- セキュリティ センター(Workspace)
- Google Workspace 管理コンソールのセキュリティ分析ダッシュボード。セキュリティの健全性ページ・調査ツール・アラートで、リスクの可視化と是正を支援する。
- セキュリティ ベースライン(Intune)
- Microsoft がセキュリティ専門家の推奨に基づき事前定義した設定の束(テンプレート)を、Windows や Edge、Defender for Endpoint などにまとめて適用する仕組み。個々の設定を一つずつ選ぶ手間を省き、業界標準に沿った出発点として使い、必要に応じて個別設定を上書きできる。
- セキュリティキャンペーン
- 多数のリポジトリにまたがる同種の既存アラートを束ね、期限を決めて計画的・一括で修復する仕組み。PR ベースの修復や一括アラート管理と組み合わせ、大規模なリスク削減に使う。
- セキュリティグループ(AWS)
- インスタンス(ENI)単位で通信を制御する仮想ファイアウォール。ステートフルで戻り通信を自動許可し、許可ルールのみを持つ(拒否は書けない)。
- セキュリティグループ(Entra ID)
- リソースへのアクセス権やライセンス割り当てに使う Microsoft Entra ID のグループ。コラボ リソースを伴う Microsoft 365 Group とは別。
- セキュリティグループ(環境)
- Microsoft Entra ID のグループを使って、その環境を利用できるユーザーを制限する仕組み。環境ごとにメンバーシップで囲い込む。
- セキュリティグループ参照
- ルールの送信元/宛先に IP でなく別のセキュリティグループを指定する手法。例:ALB の SG を Web サーバー SG の許可元にする。インスタンスが増減しても IP 管理が不要で、階層(ティア)間の通信を安全に定義できる。
- セキュリティダッシュボードとアラートセンター
- セキュリティダッシュボードは組織のセキュリティ状況(共有・スパム・認証)を俯瞰する。アラートセンターは不審ログインやフィッシングなどの通知を受け、調査ツールと連携して対応する。役割が異なり組み合わせて使う。
- セキュリティテスト(SAST/DAST/SCA)
- パイプラインに組み込む脆弱性検査。SAST=ソースの静的解析、DAST=稼働中アプリの動的解析、SCA(依存関係スキャン)=OSS の既知脆弱性検出、IaC/コンテナイメージスキャン=設定不備/イメージ脆弱性。動かさない検査は左(早期)、動的検査は右(デプロイ後)に置く。
- セキュリティパッチ管理
- OSやミドルウェア、アプリケーションに提供される修正プログラム(パッチ)を、脆弱性情報の収集から検証・適用計画・展開・適用確認まで組織的に運用するプロセス。適用の遅れは既知の脆弱性を突かれる直接原因になるため、資産管理台帳との連携が重要。
- セキュリティルールセットと強制境界
- 必須機能・必須チェック・修復 SLA などを定義し組織横断で強制する仕組み。強制境界で適用範囲(Enterprise 全体/特定組織/特定リポ群)を定める。定義だけでなく強制してこそ守られる。スイート横断で複数の柱をまとめて強制できる。
- セキュリティロール(Dataverse)
- Dataverse でテーブル/列/行(レコード)ごとの作成・読取・更新・削除権限をまとめた役割。ユーザーやチームに割り当てて最小権限を実現する。
- セキュリティ警告(脆弱性フィルタリング)
- 危険なパターン(脆弱な暗号・インジェクションを招く書き方など)の提案を検出・抑制する補助。専用スキャンと検証の代替ではない。
- セグメンテーション
- 市場をニーズや属性(年齢・地域・嗜好など)が似た顧客グループに分けることです。マーケティングでは、分けたグループの中から狙う相手を絞り込み(ターゲティング)、その層に合った商品や訴求を考える出発点になります。
- セッション(ステートレス構成)
- ユーザーとの一連のやり取りの状態を指す。サーバーにセッション情報を保持しない「ステートレス構成」にすると、どのサーバーがリクエストを処理しても差し支えなくなり、スケールアウトしやすくなる。
- セッションアフィニティ
- ロードバランサーが、同じクライアントの要求を同じバックエンドへ送り続ける設定。状態を持つ接続で使う(ステートレス設計が望ましい場合もある)。
- セッションプーラー(接続プール)
- 多数のアプリ接続で接続が枯渇しないよう、確立済み接続を再利用する仕組み。確立コストを抑え高並行でも安定させる。都度接続は枯渇の原因になる。
- セッションブロッキング
- あるセッションが保持するロックを別セッションが待つ状態。長時間化やデッドロックの兆候を DMV で特定し、クエリ/インデックス/分離レベルで解消する。
- セッションホスト
- Azure Virtual Desktop でユーザーのデスクトップ/アプリを配信する Windows 仮想マシン。ホストプールに登録トークンで参加し、リバース接続(送信 443)でクライアントと結ばれる。
- セッションポリシー
- AssumeRole 時にプログラムで渡す一時的なインラインポリシー。引き受けるロールの権限をその場でさらに絞り込む(権限を増やすことはできない)。
- セッション維持(スティッキーセッション)
- ロードバランサが同一クライアントからの一連のリクエストを常に同一の実サーバへ振り分ける機能。送信元IPアドレスに基づく方式や、Cookieにサーバ識別子を埋め込む方式がある。サーバ側にセッション状態(ログイン情報等)を保持するアプリケーションで、リクエストごとに異なるサーバへ振られると状態不整合が生じるため必要となる。
- セッション鍵
- 通信のたびに新たに生成し、その通信セッション限りで使い捨てにする共通鍵。TLSやIPsecでは、公開鍵暗号や鍵交換アルゴリズム(Diffie-Hellman等)でセッション鍵を安全に共有したうえで、以降の実データ通信は高速な共通鍵暗号で暗号化する。鍵が漏えいしても過去・将来のセッションへの影響を限定できる。
- セマフォ
- 複数のタスク(プロセス)が共有資源に同時アクセスするのを制御する仕組み。資源の利用可能数を示すカウンタを用い、P操作(獲得)・V操作(解放)でアクセスを排他的に管理する。
- セマンティックキャッシュ
- 表現が違っても意味的に同一の問い合わせの結果を再利用し、不要な FM 呼び出しを削減するキャッシュ手法。**問い合わせの埋め込みベクトルの類似度**でキャッシュヒットを判定する点が、文字列一致や決定的ハッシュによる完全一致キャッシュ(プロンプトキャッシュ等)と異なる。
- セマンティックバージョニング(SemVer)
- MAJOR.MINOR.PATCH の3部構成で互換性の変化を伝えるバージョン番号規約。MAJOR は破壊的変更、MINOR は後方互換の機能追加、PATCH は後方互換のバグ修正を意味する。パッケージ管理やAPIの後方互換性判断の共通言語として使われる。
- セマンティックモデル
- Power BI の「意味の層」(旧データセット)。テーブル・リレーションシップ・メジャー・階層・書式をまとめ、レポートが参照する。
- セマンティックモデルと DAX(メジャー・CALCULATE・ストレージモード)
- Power BI の「意味の層」(旧データセット)。リレーションシップ(ファクト↔ディメンションは原則 1 対多・単一方向)、メジャー(集計式・遅延評価・非保存)と計算列(行ごとに事前計算・保存=肥大化しがち)、階層/書式で構成。DAX(Data Analysis Expressions)は行コンテキストとフィルターコンテキストで評価され、CALCULATE がフィルターコンテキストを変更する中核(FILTER/ALL/USERELATIONSHIP と併用、TOTALYTD/SAMEPERIODLASTYEAR でタイムインテリジェンス)。ストレージモード=Direct Lake(OneLake の Delta を直接メモリにロード・高速+ほぼ最新・条件未達で DirectQuery にフォールバック)/インポート(最速・更新スケジュール要)/DirectQuery(常に最新・遅め)。列ストアエンジン VertiPaq が圧縮/集計を高速化。
- セマンティックモデルの更新(監視)
- Power BI のセマンティックモデルにデータを取り込み直す処理。失敗や所要時間を監視し、Direct Lake では更新の挙動が異なる点に注意する。
- セマンティックランカーとベクトル検索
- 検索結果を意味的関連性で並べ替えるセマンティックランカーと、埋め込みベクトルで類似検索するベクトル検索。両者とキーワードを組み合わせるハイブリッド検索が RAG の品質を高める。
- セルフサービスパスワードリセット(SSPR)
- ユーザーが管理者を介さずにパスワードを再設定できる Entra の機能。複数の認証方法を必須化し、オンプレへのパスワードライトバックにも対応する。
- セルフホストランナー
- 自分のマシン/クラウドにランナーアプリを入れて登録するランナー。特殊ハードウェア・社内ネットワークアクセス・大規模キャッシュ向け。状態が残り得るため、公開リポジトリでの利用は危険。
- セルラー通信
- 携帯電話網が提供する無線通信方式。Wi-Fiが免許不要の周波数帯を使うのに対し、セルラー通信は通信事業者が政府から割り当てを受けた免許制の周波数帯を使い、広いエリアをカバーする基地局(セル)を通じて通信する。
- セル生産方式
- 少人数の作業者(1人〜数人)が部品の取り付けから検査まで一連の工程をU字型のセルと呼ばれる作業スペースで担当する生産方式。ベルトコンベア型のライン生産と異なり、製品の切り替えが容易で多品種少量生産や需要変動への対応力が高く、作業者の多能工化によるモチベーション向上も期待できる。ITストラテジストは需要の変動幅や製品バリエーションの多さから、ライン生産とセル生産のどちらが自社の生産戦略に適するかを判断する。
- ゼロトラスト
- 「決して信頼せず、常に検証する」という指針。内側でも毎回ID・デバイス・状況を検証する。
- ゼロトラスト(考え方)
- 社内ネットワークの内側だから安全という従来の前提を置かず、すべてのアクセスを都度検証するというセキュリティの考え方。社外からのアクセスやクラウド利用が増えた環境に適したモデルとされる。
- センサとアクチュエータ
- センサは温度・光・加速度などの物理量を電気信号に変換して取得する入力デバイス。アクチュエータは電気信号を受けてモータ・バルブなどを駆動し物理的な動作を行う出力デバイス。IoTシステムはセンサで状態を取得し、判断・制御を経てアクチュエータで環境に作用する入出力の対をなす。
- ソースからのビルドとインストール
- ソースコードを取得(git clone や tar 展開)し、必要に応じて patch を当て、configure でビルド設定を生成したうえで make・make install によりコンパイルとインストールを行う一連の手順。パッケージ管理システムを介さずソフトウェアを導入する方法。
- ソートマージ結合
- 両テーブルを結合列であらかじめソートしてから、両者を同時に走査してマッチする行をマージしていく結合アルゴリズム。ソート済み(インデックス済み)データに強く、主に等値結合に用いられる。大量データでもソート済みなら安定した性能を出せ、ハッシュ結合と使い分ける。
- ゾーンファイル
- DNS ゾーンに属するリソースレコード(SOA・NS・A・MX 等)を記述したテキストファイル。BIND ではこのファイルをもとに named がドメインの名前解決情報を提供する。
- ゾーン冗長(Azure SQL)
- リージョン内の複数の可用性ゾーンにレプリカを分散配置し、データセンター障害に耐える HA 構成。多くのサービスレベルで有効化できる。
- ゾーン転送
- プライマリ(マスター)DNS サーバーからセカンダリ(スレーブ)DNS サーバーへゾーンファイルの内容を複製する仕組み。セカンダリはこれにより最新のゾーン情報を保持する。
- ソフトウェアテストの工程(単体〜受入れ)
- 開発したプログラムを、範囲を段階的に広げながら検証していく工程。一般に単体テスト(部品ごと)→結合テスト(部品をつなぐ)→システムテスト(全体)→受入れテスト(発注者が要求どおりかを検収)の順に進む。実運用に近い環境で運用に耐えるかを確かめる運用テストは、システムテストの一部、または受入れの前段として実施される。
- ソリューション(Power Platform)
- アプリ・フロー・テーブルなどの成果物をまとめて梱包し、環境間(開発→テスト→本番)へ移送する単位。マネージド/アンマネージドがあり ALM の基盤。
- ソリューションチェッカー
- ソリューション内のアプリ/フローを静的解析し、パフォーマンス・信頼性・保守性・セキュリティの問題を指摘するツール。本番移送前の品質チェックに使う。
- ソリューションビジネス
- 個々の製品を単体で売るのではなく、顧客が抱える経営課題や業務課題の解決策(ソリューション)を、ハードウェア・ソフトウェア・サービスを組み合わせて提供する事業形態。SaaS/PaaS/IaaSなどのクラウド利用型や、システム構築・運用を一括受託するアウトソーシング型などの形態がある。
- ソリューション依存関係
- ソリューションのコンポーネントが依存する他コンポーネント。移送時は依存先を含めて正しい順序で展開する。
- ソリューション層(solution layers)
- 複数ソリューションが同じコンポーネントを変更したとき、層が積み重なり最上位の層が有効になる仕組み。環境変数(値の外部化)とは別概念。
- ソルトとストレッチング
- パスワードをハッシュ化して保存する際の強化策。ソルトは利用者ごとに異なるランダム値を付加してレインボーテーブル攻撃を無効化し、ストレッチング(キーストレッチング)はハッシュ計算を多数回繰り返して総当たり攻撃のコストを引き上げる。
- ターゲットグループ属性 / 登録解除遅延
- ターゲットグループの挙動設定。登録解除遅延(コネクションドレイン)=処理中のリクエストを完了させてから外す待機時間。スティッキー時間・スロースタート・正常/異常しきい値・ヘルスチェック間隔などを調整する。
- ダーティリード
- 他のトランザクションがまだコミットしていない(ロールバックされるかもしれない)変更を読んでしまう読取り異常。隔離性水準 READ UNCOMMITTED でのみ発生しうり、READ COMMITTED 以上では防止される。
- ターンアラウンドタイムとレスポンスタイム
- ターンアラウンドタイムは利用者が処理を依頼してから全ての結果を受け取り終えるまでの総所要時間で、投入から完了までを測る。レスポンスタイムは依頼を出してから最初の応答が返り始めるまでの時間で、応答の速さ(体感)を測る。システムアーキテクトは対話型システムではレスポンスタイム、バッチ処理ではターンアラウンドタイムを主要な性能指標として設計・評価する。
- タイムアウト関連パラメータ(statement_timeout/lock_timeout/idle_in_transaction_session_timeout)
- 暴走クエリやセッション滞留を防ぐタイムアウト系パラメータ。statement_timeout は1文の実行時間上限、lock_timeout はロック取得待ちの上限、idle_in_transaction_session_timeout はトランザクションを確定せず放置されたセッション(idle in transaction)を強制終了するまでの時間を制御する。
- タイムアウト設計
- 応答を待つ上限時間をあらかじめ決めておく回復力設計の基本。設定しないと障害中の依存先を無限に待ち続け、スレッドや接続などのリソースを枯渇させて呼び出し元まで巻き込む連鎖障害を招く。上位・下位の呼び出し階層でタイムアウトを短く重ねる設計が推奨される。
- タイムアンドマテリアル契約(T&M)
- 作業時間の単価と使用した資材の実費を組み合わせて支払う契約類型。定額契約と実費償還契約の中間的な性質を持ち、小規模で作業範囲が事前に確定しにくい追加開発や保守作業に適する一方、上限を設けないとコストが青天井になるリスクがある。
- タイムインテリジェンス
- 前年比・年初来累計・移動平均など、日付ディメンションを前提にした時系列の DAX 計算(TOTALYTD・SAMEPERIODLASTYEAR 等)。
- タイムスタンプ
- ファイルの最終更新・アクセス・変更の日時。touch で更新でき、find -mtime などで更新日を条件にファイルを検索できる。
- タイムゾーン(timedatectl)
- 地域ごとの時刻設定。実体は /usr/share/zoneinfo/ 配下のファイルで、/etc/localtime をそこへのシンボリックリンクにして設定する。systemd 環境では timedatectl set-timezone Asia/Tokyo が恒久設定、TZ 変数は一時的な切り替え、tzselect は対話選択。
- ダイヤモンドモデル
- 1件の侵入をインシデントとして分析する際に、敵(Adversary)・能力(Capability)・インフラ(Infrastructure)・被害者(Victim)の4要素とその関係性で捉えるフォレンジック分析モデル。サイバーキルチェーンが時系列の段階を追うのに対し、ダイヤモンドモデルは1つの攻撃イベントの構成要素間の関係に着目する。
- タグエディタ(Tag Editor)
- アカウント内の既存リソースを横断検索し、タグを一括で追加・編集・削除できるコンソールツール。タグ付け戦略を後から徹底したい場合や、コスト配分タグの一括付与に使う。リソースを1件ずつ開いてタグ編集する手間を省く。
- タグポリシー(Organizations)
- Organizations の機能で、タグのキー名や許容値の標準を組織全体に強制し、準拠していないタグを検出する。コスト配分やアクセス制御(ABAC)の前提となるタグの一貫性を担保する。SCP とは別物(SCP は権限、タグポリシーはタグ統制)。
- タグ付け戦略
- リソースにキー/値のタグを一貫して付ける方針。コスト配分(部門別請求)、自動化(対象選択)、アクセス制御(ABAC)、棚卸しに使う。タグポリシーやコスト配分タグ、Config で準拠を強制・監視する。
- タスク(プロセス)管理
- OSが実行中のプログラムの単位であるタスク(プロセス)を管理する機能。各タスクは、CPUを使って処理中の「実行状態」、準備は整いCPUの割当て順番を待つ「実行可能状態」、入出力の完了などを待つ「待ち状態」の間を遷移する。OSのディスパッチャが実行可能状態のタスクにCPU時間を割り当て、ラウンドロビンや優先度方式などのスケジューリングで切り替えることで、見かけ上複数のタスクを並行して実行する。
- タスク自動化(SQL Server Agent・Elastic Jobs)
- 定型運用の自動化はデプロイ先で異なる。SQL Server Agent=VM/Managed Instance のジョブスケジューラ(ジョブ・ステップ・スケジュール・オペレーター通知)。Azure SQL Database は SQL Agent が無いため Elastic Jobs(ジョブエージェント+ジョブDB、ターゲットグループで複数 DB に T-SQL を並列実行)を使う。Azure Automation の Runbook(PowerShell/Python・ハイブリッドワーカー)でクラウド/オンプレ横断の運用を自動化。統計更新・インデックス再構成・DBCC CHECKDB・バックアップ検証などをスケジュール化し、失敗時に通知する。
- タスク状態遷移
- RTOS上のタスクが取り得る状態(実行中/実行可能/待ち等)とその間の遷移。実行中は1つのタスクのみでCPUを占有し、実行可能状態のタスクはスケジューラの選択待ち、待ち状態はイベントやリソースの到着待ちとなる。この遷移モデルを正しく理解することが、デッドロックや優先度逆転など不具合の原因分析の基礎になる。
- タックマンモデル
- チームの発展段階を形成期(Forming)・混乱期(Storming)・統一期(Norming)・機能期(Performing)・散会期(Adjourning)の5段階で説明するモデル。段階に応じてリーダーシップスタイルを変える必要があるという判断の根拠として重要。
- ダッシュボード(Power BI)
- 複数のレポートから重要指標(KPI)を 1 画面に集約した要約ビュー。Power BI サービス上で作成・共有する(レポートは複数ページ、ダッシュボードは 1 画面)。
- タプルと属性
- 関係モデルで、タプルは表の1行(1件のレコード)、属性は表の1列(1つの項目)を指す用語。関係代数や正規化理論の議論はこのタプル・属性の単位で行う。
- チーム テンプレート(team template)
- チャネルやアプリの定型構成を持つチームを素早く展開するためのひな型。既存グループからの作成(メンバー/リソース継承)とは別。template policies で使えるテンプレートを制御する。
- チームのアーカイブ(archive)
- Teams のチームを読み取り専用の状態にして保持する操作。チャンネルの会話とファイルは閲覧できるが投稿や編集はできなくなる。アーカイブ時のオプションで、紐づく SharePoint サイトも合わせて読み取り専用にできるが、Microsoft 365 グループ自体は残存しメンバー管理などは引き続き可能。unarchive で元の状態へ戻せる。プロジェクト終了後に記録は残しつつ操作を止めたい場合に使う。
- チームの削除と復元(delete / restore)
- チームの削除は、裏側の Microsoft 365 グループを削除することで実行される。削除後も既定で 30 日間はソフト削除状態として保持され、Microsoft 365 管理センターまたは PowerShell から restore すれば元通り復元できる。30 日を過ぎると完全に削除され復元できなくなる点に注意。
- チーム同期(team synchronization)
- IdP のグループを GitHub のチームメンバーシップに対応づけ、グループの増減を自動でチームへ反映する機能。グループ管理を IdP に一元化できる。GitHub 側で手動追加したメンバーと競合し得る。
- チェックリスト法
- あらかじめ監査目的に沿って作成した確認項目一覧(チェックリスト)に基づき、項目ごとに順に点検していく監査技法。確認漏れを防ぎ、監査人による判断のばらつきを抑えて網羅性と一貫性を確保できる一方、リストにない事項への気づきが得られにくい限界もある。
- チャネル(公開先)
- 作ったエージェントを公開する場所。Microsoft Teams、自社 Web サイト、その他のメッセージング先などに展開できる。
- チャネルの種別(standard / private / shared)
- standard はチームの全メンバー、private はチーム内の限定メンバーで専用 SharePoint サイト、shared は他チームや外部組織と共有(チーム参加不要)。
- チャレンジレスポンス認証
- サーバーが毎回異なる乱数(チャレンジ)を送り、利用者側がパスワードとその乱数から計算した応答値(レスポンス)を返す認証方式。パスワード自体を通信経路に流さないため、盗聴による再利用(リプレイ攻撃)を防げる。
- チャンキング(分割戦略)
- RAG で文書を埋め込み・検索に適した小片(チャンク)へ分割する処理。固定長/オーバーラップ付き/階層的/セマンティックチャンキング(意味の切れ目で分割)などがあり、サイズと重なりが検索精度と文脈の質を左右する。小さすぎると文脈欠落、大きすぎるとノイズ増。
- ツールキャッシュ(toolcache)
- GitHub ホスト型ランナーにプリインストールされた言語ランタイム/ツールの版を確認できる仕組み。ランナーイメージのリリースノートと併せて参照する。
- ディープパケットインスペクション(DPI)とパケットフィルタリング
- パケットフィルタリングはヘッダ情報(IPアドレス・ポート番号等)だけを見て通過の可否を判定する軽量な検査方式。ディープパケットインスペクション(DPI)はペイロード(実際のデータ内容)まで解析し、アプリケーションの種別や不正なコンテンツの有無まで検査できるが処理負荷が高い。
- ディスクストライピング
- 複数のマネージドディスクを束ねて IOPS/スループット/容量を合算する構成。単一ディスクの上限を超える SAP/HANA の性能要件に使う。単一のシンプルボリュームと区別する。
- ディスク暗号化(BitLocker)
- Windows のディスクを暗号化し、回復キーを Intune で安全に保管・取得する。self-service recovery でロックアウトしたユーザー自身が回復キーを取得できる。
- ディストリビューション
- Linux カーネルに、パッケージ管理・各種ツール・設定をまとめて配布する形態。Debian/Ubuntu 系(apt)と RHEL/CentOS 系(yum/dnf)で管理コマンドや標準構成が異なる。
- ディメンショナルモデル向けの準備
- ファクト(数値の事実)とディメンション(属性)に整え、サロゲートキーや緩やかに変化するディメンション(SCD)を扱えるよう読み込む準備。
- ディメンションテーブル
- 日付・製品・顧客など分析の切り口(属性)を持つテーブル。ファクトと 1 対多で結び、フィルターやグループ化の軸になる。
- デイリースクラム
- 開発者(Developers)が毎日行う15分(タイムボックス)の短いミーティング。スプリントゴールに向けた進捗の点検と当日の計画調整が目的で、上位者への進捗報告の場ではなく開発者の自己組織化を促す。2020年版スクラムガイドでは主体が「開発チーム」から「開発者」に改められ、毎日同じ時刻・場所で行うことは推奨だが必須ではないとされた。俗に朝会とも呼ばれる。
- ディレクトリとファイル管理
- ファイルを整理・保管するOSの仕組み。ディレクトリ(フォルダ)はファイルをまとめて入れる入れ物で、ディレクトリの中にさらにディレクトリを作る階層構造で管理する。ファイル管理では、こうした階層をたどるパス(絶対パス・相対パス)を使って目的のファイルの場所を指定する。
- ディレクトリトラバーサル
- Webアプリのファイル参照パラメータに「../」などを含めて、本来公開されていない上位ディレクトリのファイル(設定ファイル・パスワードファイル等)へ不正にアクセスする攻撃。入力値の検証とパスの正規化が対策となる。
- ディレクトリ設定
- 組織内のユーザー/連絡先の共有範囲を管理する設定。ディレクトリに表示する情報や、外部連絡先の共有可否を制御する。
- データ アクセス ガバナンス(DAG)レポート
- SharePoint で広く共有されたサイトや機微ラベルの付いたサイトを洗い出し、過剰共有のリスクを把握するレポート。是正アクションの起点になる。
- データ ライフサイクル管理と保持ラベル
- Microsoft Purview データ ライフサイクル管理は、保持ラベルで情報を必要な期間だけ保持し不要になれば削除する。コンプライアンスとストレージ最適化を両立する。
- データ/アクティビティ エクスプローラー
- データ エクスプローラー(コンテンツ エクスプローラー)は機微データの所在を、アクティビティ エクスプローラーはそのデータに対する操作を可視化する Purview のツール。
- データアセット(uri_file/uri_folder/mltable)
- 再利用可能でバージョン管理されたデータへの参照。種類は uri_file(単一ファイル)・uri_folder(フォルダー)・mltable(スキーマ付き表形式)。
- データアラート
- KPI などが設定した閾値を超えたときに通知する機能。定期配信のサブスクリプションとは目的が異なる。
- データウェアハウス
- 整形済みの構造化データを分析・集計向けに格納する基盤。スキーマは書き込み時に定義。
- データガバナンス
- どのデータを AI に渡してよいか、機微情報をどう保護するかを定める統制。生成 AI を安全に使う前提。
- データストア
- Blob/ADLS など Azure ストレージへの接続情報を安全に保持する参照。資格情報を都度書かずにデータへアクセスできる。
- データストアの選択(レイクハウス/ウェアハウス/Eventhouse)
- 用途で使い分ける。Spark/非構造化はレイクハウス、フル T-SQL/トランザクションはウェアハウス、ストリーミング/時系列は Eventhouse。
- データセット
- レポートが参照する、取り込み・整形済みのデータとモデル(テーブル・リレーション・メジャー)。1 つを複数レポートで共有できる。Power BI では 2023 年 11 月に「セマンティックモデル(semantic model)」へ名称変更された。
- データソース
- アプリが読み書きするデータの接続先。Dataverse・SharePoint・Excel・SQL・各種 SaaS などにコネクタ経由でつなぐ。
- データディクショナリ
- テーブル定義・カラムの型や制約・インデックス・権限などのメタデータを一元管理する仕組み。DBMS が自動生成し、システムカタログとして問合せ・設計変更・アクセス制御の判断根拠になる。
- データテーブル(コントロール)
- レコードを表形式(行と列)で表示する読み取り用コントロール。一覧表示に使い、ギャラリーよりも表的な見せ方に向く。
- データドリブン経営
- 勘や経験だけに頼らず、業務や市場から収集したデータの分析結果に基づいて経営判断を行う考え方。売上や顧客行動などのデータを可視化・分析する基盤を整え、意思決定のスピードと精度を高めることを狙う。ITストラテジストはデータ利活用の仕組みを事業戦略に組み込み、経営層が根拠のある判断を下せる体制の構築を推進する。
- データのインポート/エクスポート(Dataverse)
- Excel/CSV などからテーブルへ取り込み、またはテーブルから書き出す操作。列のマッピングや重複検出を伴う。Dataflows で継続的な取り込みもできる。
- データのマージと結合
- 複数のテーブルをキーで結び付けて 1 つにする変換。内部/左外部などの結合種別で一致/不一致行の扱いが変わる。
- データの暗号化(保管時・通信時)
- 情報漏えい対策として、データが記憶媒体に保存されている状態(保管時/at rest)とネットワークを移動している状態(通信時/in transit)の両方を暗号化する考え方。保管時暗号化はディスクやファイルを暗号化し、盗難・不正な持ち出しがあっても内容を読めなくする。通信時暗号化はTLS等で通信経路を保護し、盗聴や中間者攻撃による内容の窃取・改ざんを防ぐ。どちらか一方だけでは情報のライフサイクル全体を守れないため、両方を満たすことが基本要件となる。
- データの温度と階層化(ホット/ウォーム/コールド)
- アクセス頻度でデータを分類し、コストを最適化する考え方。ホット=頻繁(高速・高コスト)、ウォーム=時々、コールド=めったに(安価・取り出し遅い、Glacier 系)。S3 ライフサイクルや Intelligent-Tiering で自動的に階層を移す。
- データの視覚化(ビジュアル)
- 棒・折れ線・円・地図・表・KPI などのグラフ部品でデータを見せること。レポートに配置して傾向や比較を一目で伝える。
- データの状態(転送中/保存/使用中)
- データが情報システム内でどの状態にあるかによって、適切な保護方法が異なるという考え方。転送中のデータ(ネットワークを移動中)はTLS/IPsec等の暗号化通信で、保存データ(ディスクやストレージに保管中)はディスク暗号化で、使用中のデータ(メモリ上で処理中)はメモリ保護等で守る。
- データの探索とパフォーマンス診断(DAX/T-SQL/KQL・Performance Analyzer)
- 探索はクエリ言語を用途で使い分け:DAX(セマンティックモデルの集計)/T-SQL(SQL 分析エンドポイント・Warehouse の表分析)/KQL(Real-Time のストリーミング/ログ)。Power BI のビジュアル探索(スライサー/ドリルダウン)も用いる。性能トラブルは Performance Analyzer で各ビジュアルの DAX クエリ時間/表示時間を計測→DAX Studio や Tabular Editor のベストプラクティスアナライザーで深掘り→ストレージエンジン(VertiPaq・速い)vs フォーミュラエンジン(単一スレッド・遅くなりがち)の比率を確認。根本対処はスタースキーマ化・メジャー見直し・Delta の V-Order/OPTIMIZE・Direct Lake のフォールバック回避。「まず計測→原因特定→改善」。
- データの役割(管理者/エンジニア/アナリスト)
- データベース管理者はデータベースの可用性・セキュリティ・性能を担い、データエンジニアはパイプラインで取り込み・変換し、データアナリストは可視化と分析で洞察を導く。
- データパイプライン(Fabric)
- Copy やノートブックなどのアクティビティをオーケストレーション(順序・スケジュール・再試行・分岐)する取り込み/処理の仕組み。Data Factory エクスペリエンスで作る。
- データプレーン vs コントロールプレーン RBAC(Cosmos DB)
- Cosmos DB のアクセス制御の 2 面。コントロールプレーンはアカウント/構成の管理を Azure RBAC で、データプレーンは項目の読み書きを Microsoft Entra ID ベースの RBAC で制御する。アカウントキーよりトークン認証が推奨される。
- データフロー解析(source→sink)
- CodeQL が「危険な値がどこ(source)から入り、どこ(sink)で悪用され得るか」を経路として示す解析。原因と影響範囲、検証/サニタイズを入れる箇所が分かる。
- データプロファイル(列の品質/分布/プロファイル)
- Power Query で列の品質(有効/エラー/空)・分布(個別/一意)・プロファイル(最小/最大/平均等の統計)を評価する機能。既定は先頭1000行で全体評価に切替可能。
- データベースクラスタ
- 1つの PostgreSQL サーバインスタンスが管理する、複数のデータベースをまとめたファイルシステム上の領域全体。initdb で作成されるデータディレクトリに対応し、複数のデータベースやロールを内包する。
- データベースシャーディング
- データを複数の DB(シャード)に水平分割して拡張する設計。Elastic Database tools のシャードマップマネージャーがルーティングと管理を担う。
- データベーススコープ構成
- MAXDOP やレガシ基数推定など、サーバー設定をデータベース単位で上書きする構成(ALTER DATABASE SCOPED CONFIGURATION)。
- データベースの正規化
- データの重複や矛盾を排除するため、表を段階的に分割して整理する設計手法。更新時の不整合(更新異常)を防ぎ、データの整合性を保ちやすくする。
- データベースプロジェクト
- ウェアハウス等のスキーマをコードとして管理し、ソース管理・差分デプロイできる仕組み(SQL プロジェクト)。
- データベースユーザー
- SQL Server(および Azure SQL)のデータベースレベルのセキュリティプリンシパル。ログインにマッピングされ、ロールメンバーシップや GRANT/DENY/REVOKE を通じてオブジェクトへのアクセス許可(認可)を決める。DENY は SQL Server の T-SQL 固有の権限状態で、PostgreSQL や MySQL には存在しない。ログイン無しで作る「コンテインドユーザー」と対比される。
- データベースロール/ユーザー
- PostgreSQL では「ユーザー」と「グループ」を統一した概念としてロールを扱う。CREATE ROLE ... LOGIN でログイン可能なロール(ユーザー相当)を作成でき、既定属性(LOGIN の有無・スーパーユーザー権限など)や有効期限(VALID UNTIL)を指定できる。ALTER ROLE で属性を変更、DROP ROLE で削除する。
- データベース移行(評価・DMS・オンライン/オフライン)
- オンプレ等から Azure SQL へ移す流れ。まず評価(Data Migration Assistant/Azure Migrate で互換性チェック・推奨先・SKU 見積り)→実行(Azure Database Migration Service や Azure SQL Migration 拡張、MI 向けは Log Replay Service)。停止を許容できるオフライン(一括コピー)か、変更を継続同期し最後にカットオーバーするオンライン(停止最小)を選ぶ。移行後は互換性レベル調整と Query Store で性能退行を確認。移行先は「インスタンス機能の要否・OS 制御の要否・許容停止時間」で判断。
- データマイニング
- 大量のデータから統計的手法や機械学習を用いて、人手では気づきにくい規則性・相関・パターンを発見する分析手法。「一緒に購入されやすい商品の組合せ」のようなバスケット分析はその代表例。
- データモデリング
- 業務で扱う情報の構造を、実体(エンティティ)と関連(リレーションシップ)として抽象化し、概念・論理・物理の各段階で整理する設計技法。E-R図を用いてエンティティ間の多重度や属性を明確化し、後続のデータベース設計の基礎とする。
- データリーク
- テストデータや未来の情報、分割前のfit処理、重複レコードなどが誤って学習データに混入し、評価指標が実力より過大に見える現象。機械学習で最も見落としやすく、かつ最重要の落とし穴の一つ。分割は必ずfit/transformの前に行い、時系列は未来の情報を混ぜない。
- データリージョン
- Workspace の保存データを特定の地理(例: 米国/欧州)に限定し、データ所在地の規制に対応する設定。内容ベースの DLP や相手ドメインベースの信頼ルールとは別軸。
- データリネージ(データ系統)
- データがどの源泉からどの変換を経て生成されたかの来歴。影響分析・監査・トラブルシューティング・信頼性の担保に使う。
- データレイク
- 生のまま多様なデータ(構造化〜非構造化)を大量・安価に格納する基盤。スキーマは読み取り時に解釈。
- データレイクとフォーマット最適化
- S3 を中心に生(raw/bronze)→クレンジング(cleaned/silver)→キュレート(curated/gold)のレイヤーで品質を上げる設計。列指向(Parquet/ORC)化+パーティション分割+小ファイルのコンパクションで後段のスキャン量とコストを削減。更新/削除/タイムトラベルが要るなら Iceberg/Hudi/Delta のテーブルフォーマット。
- データレジデンシーとデータ主権
- データレジデンシー=データを保存する地理的な場所(リージョン)。データ主権=データがその国の法律の管理下に置かれること。
- データ圧縮(行/ページ)
- 行圧縮・ページ圧縮でストレージと I/O を削減する。読み取り中心の大規模表では列ストアと併せて効果が大きい。
- データ可視化とレポートの種類
- 目的に応じてビジュアル(棒・折れ線・円・マトリックス・マップ・KPI)を選ぶ。対話的なレポートと、印刷向けに整形したページネーションレポートがある。
- データ型(INTEGER/NUMERIC/VARCHAR/TEXT/BOOLEAN/DATE/TIMESTAMP/JSON/JSONB)
- PostgreSQL の主要な列データ型。INTEGER/BIGINT は整数、NUMERIC は任意精度の数値、VARCHAR は可変長文字列(長さ上限指定可)、TEXT は長さ無制限の文字列、BOOLEAN は真偽値、DATE/TIMESTAMP は日付・日時、JSON はテキストとして格納する JSON、JSONB は解析済みバイナリ形式で格納し索引化やより高速な演算が可能な JSON。
- データ型の変換
- 列の型(文字列/数値/日付など)を正しい型に変換する変換。集計や結合、書式設定を正しく行うための前提。
- データ検証・処理(取り込み前)
- RAG/学習に取り込む前にデータの品質を担保する処理。重複排除・形式統一・PII 検出/マスク・有害コンテンツ除去・メタデータ付与を行い、Glue Data Quality 等で検証する。ゴミを入れない(garbage-in 防止)ことが回答品質の土台。
- データ構造
- コンピュータでデータを効率よく扱うための、データの持ち方・並べ方のこと。同じ型を並べる配列、要素をつなぐリスト、後入れ先出しのスタック、先入れ先出しのキュー、階層状の木などがあり、目的に応じて使い分ける。
- データ取り込みと処理(パイプライン)
- Azure Data Factory / Synapse パイプラインでデータをコピー・オーケストレーションし、マッピングデータフローでコードなしに変換する。実行は統合ランタイムが担う。
- データ収集規則(DCR)
- Microsoft Sentinel/Azure Monitor で、どのソースから何を収集するかを定義する規則。Windows セキュリティイベントの収集に用い、多数のサーバーは Windows イベント転送(WEF)で集約してから送る構成もとれる。
- データ所在地(Data Residency)
- GitHub のデータを特定の地理的リージョンに保管する形態(GHEC with Data Residency)。規制・コンプライアンス要件への対応に使う。
- データ接続
- ソースへの接続を作成して取り込み/参照を行う設定。資格情報やゲートウェイ、プライバシーレベルを構成する。
- データ損失防止(DLP)
- クレジットカード番号などの機密情報の不正な共有・送信を検知・ブロックする仕組み。
- データ中心アプローチ(DOA)
- 処理よりも変化しにくいデータの構造を安定した基盤に据えて情報システムを設計する方法論。業務で扱うデータをE-R図などでモデル化して正規化し、そのデータモデルを土台に処理機能を組み立てる。処理は業務変更で頻繁に変わるが、データ構造は比較的安定しているという前提に立ち、システムアーキテクトが長期的に保守しやすいデータ資産を築く際の基本方針となる。
- データ転送料金(リージョン内/間・送出)
- AWS コストの見落としがちな要素。インターネットへの送出(egress)は有料、受信は無料。同一 AZ 内は無料、AZ 間/リージョン間は課金。NAT ゲートウェイ経由や AZ 跨ぎの設計はコストに直結する。VPC エンドポイントで NAT 経由の転送を削減できる。
- データ品質の処理(重複・欠損・遅延到着)
- 品質対策。重複は一意キーで排除、欠損は既定値や除外で扱い、遅延到着データ(後から届く過去分)はウィンドウや再処理で取り込む。
- データ分割と交差検証
- モデル評価のためデータをtrain(学習)/validation(チューニング)/test(最終評価)に分割する手法。汎化性能の見積もりにはk分割交差検証、時系列データは時間順(walk-forward)で分割し、クラス不均衡には層化抽出を使う。分割方法を誤ると評価結果が信頼できなくなる。
- データ分類(機微情報の種類・学習可能な分類子)
- データ分類は、機微情報の種類(クレジットカード・マイナンバー等のパターン)や学習可能な分類子で内容を識別する仕組み。秘密度ラベルや DLP の適用判断に使う。
- データ保護と可用性・DR(バックアップ/復元・HA/DR・PITR・LTR・geo・フェイルオーバーグループ)
- Azure SQL は自動バックアップ(フル/差分/ログ)を取得。特定時点復元 PITR=保持期間(既定7日・最大35日)内の任意時点へ復元。長期保持 LTR=週/月/年で最大10年。geo 復元=GRS の geo 冗長バックアップから別リージョンへ復元(非同期=RPO 大きめ)。HA はゾーン冗長(リージョン内・AZ 間)、DR はアクティブ geo レプリケーション(別リージョンに読み取り可能な副)とフェイルオーバーグループ(複数 DB をリスナー越しに接続文字列を変えず自動フェイルオーバー)。VM は Always On 可用性グループ。設計は RPO/RTO で判断し、同期は RPO≈0・非同期は距離を稼ぐ。
- データ保護機能(論理削除/不変ストレージ)
- 誤削除や改ざんからデータを守る機能群。論理削除(soft delete)は一定期間内なら削除データを復元でき、バージョニングは過去バージョンを保持、不変ストレージ(WORM・時間ベース/法的保持)は保持期間中の上書き/削除を禁止してコンプライアンスを満たす。
- データ利活用
- 業務の中で蓄積されたデータを分析し、経営判断や業務改善に役立てる取り組み。データをただ「持っている」だけで終わらせず、分析結果を実際の判断や行動に結びつけることが重要とされる。
- テーブル(Dataverse)
- Dataverse でデータを格納する単位(行の集合)。標準テーブル(取引先企業など既定)とカスタムテーブル(独自定義)がある。旧称エンティティ。
- テーブルのアクセス許可(Power Pages)
- 外部サイトの訪問者が Dataverse のどのテーブルの行を読み書きできるかを、Web ロールと組み合わせて制御する仕組み。公開=全公開ではない。
- テーブルパーティション分割
- 大きなテーブルをパーティション関数/スキームで物理的に分割し、保守やクエリを範囲単位で効率化する。古いパーティションの切り替え(SWITCH)で高速に入れ替えできる。
- テーブルフォーマット(Iceberg/Hudi/Delta)
- S3 のデータレイクに ACID トランザクション・更新/削除(upsert/delete)・スキーマ進化・タイムトラベルをもたらすオープンテーブルフォーマット。
- テーブル空間(TABLESPACE)
- テーブルやインデックスの物理データをどのディスク上のディレクトリに格納するかを指定するオブジェクト。1つのデータベース内でオブジェクトごとに異なるストレージ(高速ディスクと大容量ディスクなど)へ配置し分けるのに使う。
- テーブル定義 DDL(CREATE/ALTER/DROP TABLE・制約)
- テーブルを定義・変更・削除する DDL 文。CREATE TABLE で列と制約(PRIMARY KEY・FOREIGN KEY/foreign keys・UNIQUE・CHECK・NOT NULL)を定義し、ALTER TABLE(ALTER TABLE ADD COLUMN など)で構造を変更し、DROP TABLE で削除する。
- テーマ(Power BI)
- 配色やフォントをレポート全体に一括適用する書式設定。値に応じて強調する条件付き書式とは別物。
- テーマ(Power Pages)
- サイト全体の配色・フォント・スタイルをまとめて定義する設定。ブランドに合わせて外観を一括変更できる。
- テキスト検索・抽出コマンド(grep/egrep/fgrep/sed)
- grep は正規表現に一致する行を表示(-i 大小無視・-v 不一致行・-n 行番号・-r 再帰)。egrep(grep -E)は拡張正規表現、fgrep(grep -F)は正規表現を解釈しない固定文字列検索。sed はストリームエディタで sed 's/old/new/g' の検索置換が代表。
- テキスト前処理(トークン化/TF-IDF/n-gram)
- テキストを特徴量にする前処理。トークン化・ステミング/見出し語化で正規化し、Bag-of-Words や TF-IDF、n-gram、Word2Vec で数値ベクトル化する。
- テキスト入力
- ユーザーが文字や数値を打ち込むコントロール。書式(テキスト/数値/パスワード)や既定値、複数行などを設定できる。
- テキスト列
- 文字を格納する列。1 行テキスト・複数行テキストなどがあり、最大文字数や書式を設定できる。
- デザインスタジオ(Power Pages)
- Power Pages のサイト構築エディタ。ページ・スタイル・データ・セットアップのワークスペースで、ローコードにサイトを組み立てる。
- デザインパターン(GoFパターン)
- オブジェクト指向設計で繰返し現れる問題への再利用可能な解法を類型化したもので、GoF(Gang of Four)が23個を整理した。生成に関するパターン(Creational=Factory Method、Singleton、Builder など)、構造に関するパターン(Structural=Adapter、Facade、Proxy など)、振る舞いに関するパターン(Behavioral=Observer、Strategy、State など)の三分類から成る。システムアーキテクトは共通語彙として設計意図を伝え、実績ある構造で品質と保守性を確保する。
- デザインレビュー(ウォークスルー・インスペクション)
- 設計成果物を関係者が検証し、誤りや問題点を早期に発見する活動。ウォークスルーは作成者が主導して成果物を説明しながら参加者が指摘する非公式なレビューで、準備負荷が軽い。インスペクションはモデレータ(進行役)のもとで参加者に役割を分担させ、チェックリストに基づき体系的に欠陥を検出・記録する公式なレビューで、検出力が高い。システムアーキテクトは対象の重要度に応じてレビュー形態を選び、後工程への欠陥流出を防ぐ。
- デザイン思考
- 利用者(顧客)の視点に立ち、その人が本当に困っていることや求めていることを深く観察・共感することから出発して、新しい商品やサービスのアイデアを生み出す考え方。試作(プロトタイプ)と検証を素早く繰り返しながら改善する点が特徴で、技術起点ではなく人間起点で発想する。
- デシジョンツリー
- 複数の選択肢とその結果を樹形図で表し、各分岐の発生確率と利得から期待値を計算して最適な意思決定を導く経営科学の手法。不確実性を伴う投資判断やプロジェクト選択の評価に用いられ、各枝の期待値(確率×利得の総和)を比較して最も有利な選択肢を選ぶ。
- デジタイゼーションとデジタライゼーション
- DXに至る段階を表す用語。デジタイゼーションは紙の書類を電子化するなど、既存の業務・情報をそのままデジタルな形式に置き換える段階。デジタライゼーションは、デジタル技術を使って業務プロセスや顧客接点そのものを変革する段階で、単なる電子化にとどまらない点がデジタイゼーションと異なる。
- デジタルツイン
- IoTセンサーなどで収集した実世界の設備・製品・プロセスのデータをもとに、仮想空間上にリアルタイムで再現した分身(モデル)。シミュレーションによって実際に変更を加える前に稼働状態の予測や異常の早期検知、改善策の効果検証ができる。ITストラテジストは試作や本番停止のコストとリスクを抑えつつ設備投資や工程改善の意思決定を行う手段として活用を検討する。
- デジタルトランスフォーメーション(DX)
- クラウドなどのデジタル技術を使って製品・サービス・業務のあり方そのものを作り変え、新たな価値や顧客体験を生み出すこと。
- デジタルフォレンジックス
- インシデント発生後に、コンピュータやネットワーク機器に残された記録(ログ・ディスクイメージ・メモリダンプ等)を法的な証拠として通用する手続きで収集・保全・解析する技術と手順。原本の改変を避けるためのハッシュ値記録や証拠保全(チェーン・オブ・カストディ)が重要。
- デジタル証明書
- 認証局(CA)が発行する、公開鍵とその所有者を結び付けて正当性を保証する電子的な証明書。Webサーバーの証明書はブラウザがHTTPS接続時に検証し、なりすまされたサイトでないことを確認する。
- デジュールスタンダードとデファクトスタンダード
- 標準規格の成立過程による分類。ISO・JISなど公的な標準化団体が公式な手続きを経て制定する規格がデジュールスタンダード、公的な認定手続きを経ずに市場での実質的な普及・シェア獲得によって事実上の標準となった規格がデファクトスタンダード。
- デスクトップフロー
- RPA で画面操作(クリックや入力)を記録・再生し、API のない古いアプリも自動化する Power Automate のフロー。Power Automate for Desktop で作る。
- テストデータ法
- 監査人があらかじめ想定結果を用意したテストデータを作成し、監査対象プログラム(またはその複製)に、本番データと混同しないよう試験環境で処理させて、出力結果を想定結果と比較することでプログラムの処理内容(ロジック)の正確性を検証するCAATの一技法。プログラムそのものの妥当性確認に主眼を置く。本番データを汚染しないよう試験環境で実施するのが原則で、本番稼働中の処理に監査用の擬似データを紛れ込ませるITF法とは異なる。
- テスト駆動開発・アジャイル・ウォーターフォール
- テスト駆動開発(TDD)は実装前にテストを書き、それを通すコードを書くという順序で品質を組み込む手法。アジャイルは短い反復(スプリント)で計画・実装・見直しを繰り返し変化に適応する開発手法。ウォーターフォールは要件定義→設計→実装→テストを一方向に順に進める手法で、要件が固まっているプロジェクトに向く。
- デッドレターキュー(DLQ)
- 規定回数の処理に失敗したメッセージを退避する専用キュー。原因調査や再処理に使い、正常キューが毒メッセージで詰まるのを防ぐ。maxReceiveCount で移送のしきい値を決める。
- デッドロック
- 複数のトランザクションが互いに相手の保持するロックの解放を待ち合い、いずれも先へ進めなくなる状態。PostgreSQL は自動的にデッドロックを検出し、いずれか一方のトランザクションを強制的にロールバックさせて解消する。
- デッドロック
- 複数のプロセスやトランザクションが互いに相手の保持する資源の解放を待ち合い、いずれも処理を進められなくなる膠着状態。相互排他・保持と待機・横取り不可・循環待ちの4条件が同時に成立すると発生し、資源獲得順序の統一による予防、資源要求のスケジューリングによる回避、待機グラフの監視による検出と一方のロールバックといった対策がある。システムアーキテクトはロック粒度と獲得順序を設計してデッドロックを抑止する。
- テナントネットワーク
- クラウド環境で利用者(テナント)ごとに分離された仮想ネットワーク。他のテナントと通信経路が隔離され、セキュリティグループなどと組み合わせてアクセス制御する。
- テナント間同期(cross-tenant synchronization)
- 複数の Entra テナント間で、あるテナントのユーザーを別テナントへ B2B ゲストとして自動プロビジョニングする仕組み。手動招待を不要にする。相手テナントの信頼/アクセスを制御する Cross-tenant access 設定とは別機能。
- テナント構成(ドメイン/組織設定)
- 独自ドメインの追加(DNS TXT 検証)と Organization profile(組織名・連絡先・リリース設定)など、Microsoft 365 admin center で行うテナント全体の基本構成。
- テナント設定(管理ポータル)
- Fabric 管理者がテナント全体で機能の可否(エクスポート・共有・特定機能の有効化など)を統制する設定。
- デバイスコンプライアンス
- デバイスが Intune のポリシー要件(暗号化・OS バージョン・パスコード等)を満たしている状態。条件付きアクセスと組み合わせ、準拠デバイスのみアクセスを許可できる。
- デバイスドライバ
- 特定のハードウェア(センサ、通信モジュール等)を制御するためのレジスタ操作を抽象化し、上位のアプリケーションソフトウェアに統一的なインタフェースを提供するソフトウェア層。ハードウェアの詳細をアプリケーションから隠蔽することで、ハードウェア変更時の影響をドライバ層に限定でき、移植性と保守性を高める。
- デバイス管理(udev/sysfs/D-Bus)
- デバイスの抜き差し(ホットプラグ)を検知し、/dev のデバイスファイルを動的に作成・命名する仕組みが udev。sysfs(/sys)はカーネルが公開するデバイスツリー、D-Bus はデスクトップ等へイベントを通知するプロセス間通信。
- デバイス管理レベル(基本 / 高度)
- エンドポイント管理の強度。基本管理=登録不要で最小限の制御。高度な管理=登録のうえ画面ロック・暗号化・ワイプ等の強い制御。会社所有/個人所有(BYOD)で使い分ける。
- デバイス構成プロファイル
- 言語やセキュリティなどの設定を Intune から一元的にデバイスへ配布する(設定を配布するもので、準拠を判定する compliance policy とは役割が別)。
- デバイス登録(device registration)
- 個人所有デバイス(BYOD)を Entra ID に登録し、デバイス自体を組織管理下に置かずに、会社のリソースへのアクセスにのみ Entra ID の識別を持たせる方式。多くは Microsoft Entra ID に個人アカウントで登録し、MAM(モバイル アプリケーション管理)でアプリ単位の保護を適用する。デバイス全体を管理する Entra join / hybrid join とは管理範囲が異なる。
- デフォルトセキュリティ構成
- 「どの機能を・どの設定で有効化するか」をテンプレート化したもの。組織で適用すると対象リポへ一律に適用され、継承により以後作られるリポにも自動で効く。GitHub recommended か組織独自のカスタムを選べる。
- デフォルトルート(0.0.0.0/0)
- ルートテーブルで「他のどのルートにも一致しない宛先」を送る既定の経路。パブリックサブネットでは IGW を、プライベートサブネットでは NAT ゲートウェイを指す。外向き通信の出口を決める。
- デフォルトルート(デフォルトゲートウェイ)
- 宛先が自分のネットワーク外のパケットを託す出口。ip route(または route -n)で確認し、無いと外部へ一切出られない。ルーティングテーブルの誤りは ip route del/add default で訂正する。
- デプロイパイプライン(Fabric)
- 開発→テスト→本番のステージ間で成果物を昇格し、差分比較やデプロイ規則を適用するリリース機能。手動配置のミスを防ぐ。
- デプロイメントスロット
- App Service で本番とは別の環境(ステージング等)にデプロイし、暖機後にスワップで無停止リリースする仕組み。問題時は元に戻せる。
- デプロイモデル
- クラウド配置の分類。パブリック(共有)、プライベート(専有)、ハイブリッド(両方を連携)。
- デプロイ形態(GHEC/EMU/Data Residency/GHES)
- 要件で選ぶ提供形態。GHEC with EMU(ID 完全管理)、GHEC with Data Residency + EMU(データ所在地を指定)、個人アカウントの GHEC、GHES(完全自社管理)。
- デプロイ戦略(Blue/Green・カナリア)
- 新バージョン公開の方式。オールアットワンス=一括(停止リスク)、ローリング=バッチ更新、Blue/Green=新環境へ切替(ロールバック容易)、カナリア=少量から段階移行。速度と安全のトレードオフで選ぶ。
- デプロイ戦略(カナリア/ブルー・グリーン/ロールバック)
- カナリア=一部の利用者に先行公開、ブルー/グリーン=新旧環境を瞬時に切替、ロールバック=問題時に即座に戻す。リスクを抑えてリリースする手法。
- デュアルシステム
- 同一処理を行う2系統のコンピュータシステムで常時互いの処理結果を照合し、信頼性を高める構成。片方に障害が発生すればそのシステムを切り離し、残る1系統で処理を続行する。
- デュアルスタック VPC(IPv4/IPv6)
- 1 つの VPC・サブネットで IPv4 と IPv6 の両方のアドレス体系を併用する構成。IPv6 アドレスはすべてグローバルにルーティング可能でアドレス枯渇の心配がないが、外向き通信のみ許可し着信を防ぎたい場合は送信専用インターネットゲートウェイ(egress-only internet gateway)を使う。
- デュプレックスシステム
- 主系(現用系)と従系(待機系)の2系統で構成し、主系が処理を担当し従系は待機する方式。従系の待機形態によりホットスタンバイ・ウォームスタンバイ・コールドスタンバイに分類され、切替速度とコストがトレードオフになる。2系統で同一処理を並行実行し結果を照合するデュアルシステムとは異なり、デュプレックスは片系のみが本番処理を行い他系は待機する点で対比される。
- デリゲーション(委任)
- 絞り込みや並べ替えの処理を、アプリ側ではなくデータソース側で実行させる仕組み。大量データでも正しく速く扱える。非対応の関数を使うと一部しか処理されない点が注意点。
- テンプレートデータベース(template0/template1)
- CREATE DATABASE の雛形となる特殊データベース。template1 はユーザーがカスタマイズ可能な既定テンプレートで、通常の CREATE DATABASE はこれをコピーする。template0 は初期状態を保持するクリーンな雛形で、ロケールなど特殊なケースの複製元に使う。
- ド・モルガンの法則
- 論理演算における否定の分配に関する法則。「AかつBの否定」は「Aの否定またはBの否定」に等しく(NOT(A AND B)=NOT A OR NOT B)、「AまたはBの否定」は「Aの否定かつBの否定」に等しい(NOT(A OR B)=NOT A AND NOT B)。論理式の簡単化や条件式の書き換えに用いる。
- トイル(Toil)
- SREにおいて、手作業で繰り返し発生し自動化可能な運用労力を指す用語。長期的な価値を生まず、増え続けるとエンジニアの余力を奪う。SREの実践では、運用時間の一定割合をトイル削減の自動化に充てることを目標にする。
- トークン
- モデルが扱うテキストの単位(おおむね単語の一部)。料金やコンテキスト長の基準になる。
- トータルフロート
- あるアクティビティが、プロジェクト全体の完了日を遅らせることなく遅延できる最大時間(最遅開始日−最早開始日)。トータルフロートが0のアクティビティの連なりがクリティカルパスであり、フロートが0か正かを判定することが遅延対応の優先順位づけの基準になる点で重要。
- トキシックコンビネーション
- Security Command Center の概念。単体では低リスクでも組み合わさると致命的になる設定/権限の連鎖(例:公開バケット+過剰権限サービスアカウント)。攻撃経路を先回りで塞ぐために評価する。
- ドキュメントレビュー法
- 規程・マニュアル・設計書・議事録・記録類などの文書を査閲し、統制の整備状況(規程等が適切に定められているか)や運用状況(記録が実際に作成・保存されているか)を確かめる監査技法。文書上の整合性は確認できるが、記載どおりに実施されているかは他の手続と組み合わせて裏付ける必要がある。
- ドキュメント指向データベース
- JSON のような半構造化ドキュメント単位でデータを格納する NoSQL のモデル。ドキュメントごとに異なる項目を持てる柔軟なスキーマが特徴で、階層的・可変的な構造のデータに向く。
- ドキュメント翻訳とカスタム翻訳
- Translator のドキュメント翻訳は書式を保ったままファイルを翻訳し、カスタム翻訳(Custom Translator)は対訳データで業界固有の用語に適応したモデルを学習・公開する。
- トグル(切り替え)
- オン/オフを切り替えるスイッチ型のコントロール。真偽値(はい/いいえ)の入力に使う。チェックボックスと似た用途。
- トピック(Copilot Studio)
- ユーザーの意図ごとに会話の流れを定義する単位。トリガーフレーズで起動し、質問やメッセージ、条件分岐でやり取りを組み立てる。
- トピックとサブスクリプション(Service Bus)
- 1 つのメッセージを複数の受信者へ配る pub/sub。サブスクリプションごとにフィルターで受け取るメッセージを選別できる。
- ドメイン(Fabric)
- 関連するワークスペースを業務分野(営業・財務など)でまとめる論理グループ。データメッシュ的に分散管理し、ドメイン単位で既定値や委任管理を設定できる。
- ドメイン駆動設計(DDD)
- 業務ドメインのモデルを設計の中心に据え、そのモデルを軸にソフトウェアを構築する設計手法。開発者と業務担当者が共有するユビキタス言語で認識を合わせ、境界づけられたコンテキストでモデルの適用範囲を区切って大規模システムの複雑さを分割統治する。システムアーキテクトはコンテキスト境界の切り方をサービス分割や組織構造と対応づけて判断する。
- トラフィックシェーピングとポリシング
- シェーピングは規定速度を超えるトラフィックをバッファにキューイングして送出間隔を平滑化し、パケット廃棄を避けつつ遅延を許容する制御。ポリシングは超過分を即座に廃棄またはマーキング(DSCP再設定等)するだけでバッファリングせず、遅延は増やさないが廃棄が発生しうる。シェーピングは主に送信側(下り方向の平滑化)、ポリシングは主に受信側(契約帯域超過の取り締まり)で用いられる。
- トラフィックミラーリング
- 送信元 ENI を通過する実パケットを複製し、モニタリング用の ENI や NLB 宛に送って IDS やパケットキャプチャで深く検査する機能。VPC フローログがメタデータのみなのに対し、トラフィックミラーリングはペイロード(パケット本体)まで取得できる。フィルタで対象トラフィックを絞れるが、ミラー分の帯域とコストがかかる。
- トラフィック分割とブルー/グリーン
- 1 つのエンドポイントに複数デプロイを置き、トラフィックを割合配分する。新版へ段階的にロールアウトし、問題時に即ロールバックできる。
- トランクベース開発
- 短命なブランチを頻繁に main(トランク)へ統合するソース管理戦略。未完成の機能はフィーチャーフラグで隠して本番に混在させ、マージ地獄を避ける。CI/CD との相性が良く、継続的インテグレーションの前提となる。
- トランザクション(BEGIN/COMMIT/ROLLBACK)
- 複数の操作を1つの不可分な単位としてまとめる仕組み。BEGIN で開始し、COMMIT で全ての変更を確定、ROLLBACK で全ての変更を取り消す。ACID特性(原子性・一貫性・独立性・永続性)を保証し、SAVEPOINT でトランザクション内に部分的なロールバック地点を設けられる。
- トランザクションとACID特性
- トランザクションは、一連の処理をひとまとまりとして扱う単位で、途中で失敗した場合は全体を取り消す(ロールバック)。ACID特性(原子性・一貫性・独立性・永続性)は、トランザクションが満たすべき4つの性質。
- トランザクション隔離性水準
- 同時実行される複数トランザクション間で、互いの未確定な変更をどこまで見せるかを定める設定。低い順にREAD UNCOMMITTED(ダーティリードを許容)、READ COMMITTED、REPEATABLE READ、SERIALIZABLE(直列実行と等価な最も厳格な水準)の4段階があり、水準を上げるほど整合性は高まるが並行性(スループット)は低下するトレードオフがある。
- トランザクション処理と分析処理の使い分け
- OLTP は多数の小さな読み書きを高速・整合性重視で処理する業務システム向け、OLAP は大量データを集計・分析する意思決定向け。データの流れは OLTP →(ETL)→ OLAP。
- トリガー
- フローを開始するきっかけ(例:メール受信、時刻、ボタン押下)。1 つのフローに 1 つ。トリガーの後にアクションが続く。
- トリガー
- INSERT/UPDATE/DELETE などのイベント発生時に自動的に指定した関数を実行する仕組み。行レベル・文レベル、実行前(BEFORE)・実行後(AFTER)などのタイミングを指定でき、PL/pgSQL で書かれたトリガー関数と組み合わせて使う。
- トリガーとユーザー定義関数(UDF)
- サーバーサイド JavaScript。トリガーは操作に連動し、プリ(書き込み前の検証/補完)とポスト(書き込み後の処理)があり要求時に明示指定する。UDF はクエリ内で呼べるカスタム計算だが、インデックスが効きにくく RU が増えうる。
- トリガーフレーズ
- トピックを起動させるユーザー発話の例。複数登録しておくと、似た言い回しでも適切なトピックにマッチする。
- ドリルスルー
- 選択した値(例: 製品)を持って別のレポートページへ移動し詳細を見せる機能。戻るボタンで復帰。同ビジュアルで階層を下るドリルダウンとは別。
- ドリルダウン
- 同じビジュアルの中で階層(年→四半期→月など)を1段ずつ下りて詳細化する操作。別ページへ移動するドリルスルーとは別。
- ドレインモード(drain mode)
- 更新やメンテナンスのためにセッションホストを入れ替える前に、新規セッションの受け付けを止めて既存ユーザーを退避させる状態。プール型の更新は「新イメージ版発行→ドレイン→セッションホスト再作成」のサイクルで行う。
- トレースによるフロー評価
- フローの各ステップの入出力・遅延・トークン消費を記録(トレース)し、品質や性能のボトルネックを評価・改善する。
- ドロップダウン
- 候補リストから 1 つを選ばせるコントロール。選択肢列やテーブルの値を割り当てて、入力のばらつきを防ぐ。
- トンネリング
- あるプロトコルのパケットを別のプロトコルのパケットでカプセル化し、異種ネットワークや非対応区間を通過させる技術。IPv6 over IPv4(6to4など)やVPN(GRE、IPsecトンネルモードなど)で用いられ、経路上の中継機器はカプセル化前の内容を意識せず転送できる。
- ナラティブビジュアル(Copilot)
- データの要点を自然言語の文章で自動説明するビジュアル。Copilot で生成でき、生成結果は必ず検証する。
- ナレッジストア(プロジェクション)
- エンリッチメントの結果をファイル・オブジェクト・テーブルのプロジェクションとして保存し、検索以外の分析にも再利用できるようにする仕組み。
- ナレッジと生成型回答
- 社内文書や Web サイトを知識源として与え、トピックを細かく作らなくても生成 AI が自然な回答を返す仕組み(生成型回答)。
- ナレッジ管理(SKMS)
- 既知の誤り、対応手順、FAQといったナレッジを組織的に蓄積・共有し、対応の効率と品質を高めるプロセス。これらを支える情報基盤がサービスナレッジ管理システム(SKMS)で、必要な情報を適切な担当者へ適時に届け、判断の再現性と一次解決率の向上を狙う。SKMSはCMS(構成管理システム)やCMDBを包含する上位の知識基盤(DIKWモデル=データ・情報・知識・知恵の階層に基づく)であり、既知の誤りそのものは主にKEDB(既知の誤りデータベース)で管理される。
- ニューラルネットワーク
- 生物の神経細胞(ニューロン)の仕組みを模したモデルで、入力に重みを掛けて足し合わせ、活性化関数を通して出力するユニットを多層に結合した計算モデル。学習時には出力の誤差を逆伝播(バックプロパゲーション)させて各層の重みを更新し、入力と出力の関係を近似する。
- ネイティブVLAN
- トランクポート上でIEEE 802.1Qのタグを付与せずに転送される既定のVLAN。トランク両端でネイティブVLANの設定が一致していないと、フレームが誤ったVLANに届いたりVLANホッピング攻撃を許したりする問題が生じる。
- ネステッドループ結合
- 外側テーブルの各行に対し、内側テーブルを毎回走査して結合条件に合う行を探す結合アルゴリズム。片方が小さい、あるいは内側の結合列にインデックスがある場合に有効だが、両方が大きいと比較回数が乗算的に増える。
- ネットワーク ACL(NACL)
- サブネット単位で通信を制御する仕組み。ステートレスで戻り通信も明示許可が必要。許可と拒否の両方を書け、特定 IP のブロックは NACL の役割。
- ネットワークアドレスとブロードキャストアドレス
- IPv4サブネットにおいて、ネットワークアドレスはホスト部をすべて0にした先頭アドレスでそのネットワーク自体を識別し、ブロードキャストアドレスはホスト部をすべて1にした末尾アドレスでサブネット内全ホストへの一斉送信に用いる。いずれもホストには割り当てられず、利用可能ホスト数は総アドレス数から2を引いた値になる。
- ネットワークエンドポイントグループ(NEG)
- ロードバランサのバックエンド単位。コンテナネイティブ(GKE)・サーバーレス(Cloud Run など)・インターネットのエンドポイントをまとめて登録できる。マネージドインスタンスグループ(MIG)と使い分ける。
- ネットワークセキュリティグループ(NSG)
- サブネットやNIC単位で送信元・宛先・ポートに基づく許可/拒否ルールを適用する。
- ネットワークセグメンテーション
- ネットワークを複数の小さな区画に分割し、区画間の通信をファイアウォールやVLANで制御する設計。ある区画が侵害されても被害が他の区画へ広がりにくくなり、影響範囲を限定できる。
- ネットワークティア
- 下り通信の経路品質を選ぶ階層。Premium(Google バックボーン中心・高品質)と Standard(コスト優先)で性能とコストをトレードオフする。
- ネットワークトポロジ
- ネットワーク機器やケーブルの接続形態。物理的な配線の形を示す物理トポロジ(スター型・バス型・リング型・メッシュ型等)と、データが実際にたどる経路を示す論理トポロジがある。現在の企業LANはスイッチを中心としたスター型の物理配線が主流。
- ネットワークプロファイリングとサーバプロファイリング
- いずれも「通常状態」の基準値(ベースライン)を作り、そこからの逸脱を異常として検知する手法。ネットワークプロファイリングはスループット・セッション時間・使用ポート・重要資産空間等を基準にする。サーバプロファイリングはリスニングポート・ログイン中ユーザー・実行中プロセス・定期タスク・稼働アプリ等を基準にする。
- ネットワーク設定(ip/ifconfig/nmcli)
- ホストのネットワーク設定を参照・変更する。現行標準は ip コマンド(ip addr アドレス・ip route ルート)、従来は ifconfig/route。ip や ifconfig の変更は一時的で再起動で消え、恒久化は NetworkManager の nmcli や設定ファイル。ifup/ifdown は設定ファイルに基づく起動/停止。ホスト名は /etc/hostname。
- ノーコード
- コードを一切書かず、画面操作と設定だけでアプリ/自動化を作る手法。ローコードより制約は強いが、非開発者でも扱いやすい。
- ノースバウンドAPIとサウスバウンドAPI
- コントローラを基準にしたAPIの向きの呼び名。ノースバウンドAPIはコントローラが上位のアプリケーションや自動化ツールへ提供するインタフェース(例:REST API)で、サウスバウンドAPIはコントローラが配下の機器を制御するために使うインタフェース(例:NETCONF、OpenFlow)を指す。
- バーコードスキャナー
- 端末のカメラでバーコードや QR コードを読み取るコントロール。在庫・資産管理などで識別子を素早く入力できる。
- バージョニングとリリースサイクル
- PostgreSQL はメジャーバージョン(新機能を含み年1回程度リリース)とマイナーバージョン(バグ修正・セキュリティ修正のみ)を区別する。サポートポリシーにより各メジャーバージョンは初回リリースから約5年間サポートされる。
- バージョン管理システム(VCS)
- ファイルの変更履歴を記録し、過去への巻き戻し・変更者や理由の追跡・共同作業を可能にする仕組み。
- ハーズバーグの動機付け衛生理論
- 職務満足に関わる「動機付け要因」(達成・承認・仕事そのものなど)と、不満の解消に関わるが満足には直結しない「衛生要因」(給与・労働条件など)を分けて説明する理論。衛生要因を整えるだけではチームのモチベーション向上に不十分と判断する根拠として重要。
- パーティショニング
- 1つの論理テーブルを複数の物理パーティションへ分割する仕組み(宣言的パーティショニング:RANGE/LIST/HASH)。パーティションプルーニングにより不要なパーティションのスキャンを省略でき、大規模テーブルのメンテナンス(古いパーティションの高速削除など)も容易になる。
- パーティション
- 大きなテーブルを複数の物理的な子テーブルに分割して管理する仕組み。PARTITION BY RANGE のように範囲・リスト・ハッシュなどの方式で分割条件を指定し、対象範囲を絞った問い合わせの高速化や保守性向上に使う。
- パーティション(MBR/GPT)
- ディスクを区切って使う単位。区切りの台帳がパーティションテーブルで、旧来の MBR(最大 2TB・基本パーティション4個、拡張で回避)と現行主流の GPT(実質無制限・UEFI とセット)がある。
- パーティションキー(Cosmos DB)
- データを論理パーティションに分散させる列。高カーディナリティで均等分散する値を選ぶとホットパーティションを避け、RU/s を効率化できる。
- パーティションキーと論理パーティション
- Cosmos DB がデータを水平スケールする単位。同じパーティションキー値の項目が 1 つの論理パーティション(最大 20GB)にまとまる。高カーディナリティでデータ/スループットを均すキーを選ぶ。偏るとホットパーティションで 429 を招く。作成後は変更不可。
- パーティションとクラスタリング(BigQuery)
- パーティションはテーブルを日付などで分割し、クラスタリングはよく絞る列で行を整列する。どちらもスキャン量を減らし BigQuery のコスト/性能を最適化する。
- パーティション設計
- よく絞り込む列(日付など)でデータを分割し、クエリが必要な区画だけ読むようにする設計。過剰分割は small files を招くため粒度に注意。
- パーティション分割(S3/データレイク)
- データを日付や地域などのキーでフォルダー分割し、クエリで不要なパーティションを読み飛ばす(プルーニング)ことでスキャン量とコストを削減する。
- パーティション編集ツール(fdisk/gdisk/parted)
- パーティションを操作するツール。fdisk は対話式の定番(MBR/GPT 両対応)、gdisk は GPT 専用、parted は MBR/GPT 両対応でスクリプト実行も得意。fdisk -l でディスクとパーティションを一覧する。
- ハードニング
- 不要なサービスの停止、初期パスワードの変更、最新パッチの適用、最小権限の徹底などにより、システムの攻撃対象領域(アタックサーフェス)を減らし攻撃を受けにくくする作業。
- ハードリアルタイム/ソフトリアルタイム
- デッドライン超過の許容度による分類。ハードリアルタイムはデッドラインを1回でも外すとシステム障害や事故に直結する厳格な要件(エアバッグ制御等)、ソフトリアルタイムはデッドライン超過が性能劣化に留まり許容できる要件(動画再生等)を指す。要件の分類が、採用するスケジューリング方式や検証手法を左右する。
- ハードリンクとシンボリックリンク(ln)
- 1つの実体を複数の名前で参照する仕組み。ハードリンク(ln)は同一 inode の対等な別名で、同一ファイルシステム内のみ・ディレクトリ不可・元を消しても実体は残る。シンボリックリンク(ln -s)はパスを記録した特殊ファイルで、別ファイルシステムやディレクトリも指せるが元を消すと壊れたリンクになる。
- パーミッシブ系ライセンス(BSD/MIT/Apache/MPL)
- 非コピーレフト(パーミッシブ)系と中間形。BSD・MIT は最小限の条件で改変版をクローズド化できる。Apache License 2.0 は特許条項が明確。MPL はファイル単位のコピーレフト(改変ファイルだけ公開)。パブリックドメインは著作権を主張しない状態。
- パーミッションと所有者
- ファイルへのアクセスを、所有者・所有グループ・その他の3区分ごとに読み(r)・書き(w)・実行(x)で制御する仕組み。ls -l の先頭10文字で表示される。所有者は chown、所有グループは chgrp で変更する。
- バーンダウンチャート
- アジャイル開発でスプリントやリリースの残作業量を時間軸に沿ってプロットし、理想線と実績線を比較する図。実績線が理想線から乖離した場合に進捗の遅れや見積り誤りを早期に検知し、スコープ調整などの判断につなげる点で重要。
- バーンレート(エラーバジェット消費速度)
- エラーバジェット(許容される不可用時間の総量)が消費されていく速度を表す指標。通常より速いバーンレートはSLO違反が差し迫っていることを示し、複数の時間窓(例:1時間と6時間)を組み合わせたマルチウィンドウアラートで早期検知に使われる。
- バイアス(生成 AI)
- 学習データの偏りが出力に反映されるリスク。公平性の観点で確認する。
- ハイパーバイザ(Type 1/Type 2)
- 仮想マシンを動かす基盤ソフトウェアの分類。Type 1(ベアメタル型、ESXi等)はハードウェア上に直接インストールされ、ホストOSを介さないため性能・隔離性に優れ、サーバ仮想化で主流。Type 2(ホスト型、VirtualBox等)は既存のホストOS上でアプリケーションとして動作するため導入は手軽だが、ホストOSを介する分オーバーヘッドが大きく、主に検証・デスクトップ用途で使われる。仮想スイッチはこの上で仮想マシン同士やアップリンクとの接続を担う。
- ハイパーバイザー
- 物理マシンの CPU・メモリ・ディスクを仮想化し、複数の仮想マシンへ分配するソフトウェア。CPU の仮想化支援機能(Intel VT-x/AMD-V)を使って実用的な速度で動かす。Linux では KVM がその役割を担う。
- ハイパーパラメータ最適化(HPO)
- 学習前に決める設定(学習率・木の深さ・正則化強度等)を自動探索して指標を最適化すること。グリッド/ランダム探索、ベイズ最適化、早期終了を使う。SageMaker の Automatic Model Tuning が代表。検証データで評価し過学習を避ける。
- パイプ(|)
- 左のコマンドの標準出力を右のコマンドの標準入力へ直結する(ps aux | grep nginx)。標準エラーはパイプに乗らない(乗せるには 2>&1 を先に置く)。
- ハイプサイクル
- 新しい技術が市場で注目されてから成熟するまでの期待の推移を、黎明期・「過度な期待」のピーク期・幻滅期・啓発期・生産性の安定期の5段階で描いたガートナー社のモデル。ストラテジストは、話題の技術が現在どの段階にあるかを見極めることで、過度な期待のピーク期にある技術への性急な投資を避けたり、幻滅期を耐えて啓発期に入った技術への投資タイミングを判断したりするために用いる。
- パイプラインエージェント(Microsoft ホスト/セルフホスト)
- パイプラインのジョブを実行する計算環境。Microsoft ホストは毎回クリーンで管理不要、セルフホストは独自 OS/ツール・社内ネットワーク到達・GPU・キャッシュ常駐などの特殊要件や高速化に対応する。
- パイプラインジョブ
- 複数のコンポーネントを DAG として接続し、ステップ間でデータを受け渡して実行する一連の処理。スケジュール実行や監視ができる。
- パイプラインのパラメーターと動的式
- 実行時に値を渡すパラメーターと、式でその値を組み立てる動的式。同じパイプラインを環境や対象を変えて再利用できる。
- パイプラインハザードとフォワーディング
- パイプライン処理で命令間の依存により正しい実行が妨げられる問題をハザードといい、データ/制御/構造の3種がある。必要時はストール(待ち)を挿入して解消する。フォワーディング(データバイパス)は演算結果をレジスタ書き込み前に後続命令へ直接転送してデータハザードの待ちを削減する高速化技法だが、直前ロードの結果を使うロードユースハザードはフォワーディングでも1サイクルのストールを避けられない。
- パイプライン処理
- 命令の実行を「命令フェッチ・デコード・実行・書き戻し」などの段階に分割し、複数の命令の各段階を並行して処理することでCPUのスループットを高める方式。分岐命令などでパイプラインハザードが起きうる。
- ハイブリッド DNS(転送ゾーン/インバウンドポリシー/DNS ピアリング)
- オンプレと Cloud DNS の双方向の名前解決を組む構成。転送ゾーンは Cloud からオンプレへ問い合わせ、インバウンドサーバーポリシーはオンプレから Cloud を解決、DNS ピアリングは別 VPC のゾーンを参照する。
- ハイブリッド ID(Entra Connect)
- オンプレの Active Directory を Entra ID と同期してハイブリッド ID を実現する。パスワードハッシュ同期・パススルー認証・フェデレーション(AD FS)から認証方式を選ぶ。
- ハイブリッドクラウド
- パブリックとプライベート(オンプレ)を組み合わせて連携させる形態。規制とクラウドの柔軟さを両立。
- ハイブリッド暗号方式
- 共通鍵暗号の処理速度と公開鍵暗号の鍵配送の安全性を組み合わせた方式。データ本体は共通鍵で暗号化し、その共通鍵自体を受信者の公開鍵で暗号化して送る。S/MIMEやPGP、TLS1.2以前などで使われる(現行のTLS1.3では鍵交換に(EC)DHEを用い、共通鍵を公開鍵で暗号化して送る方式は使われない)。
- パケットキャプチャ(Network Watcher)
- VM の通信を実際に取得して解析する Network Watcher の機能。アプリ層の問題やNSGでは分からない事象の切り分けに使う。
- パケットミラーリング
- トラフィックを完全に複製し、自己管理の IDS/IPS コレクタなどへアウトオブバンドで送る仕組み。サンプリングの VPC フローログより精密な解析ができる。経路に挟んで遮断するインライン検査(マルチ NIC NVA)とは別。
- パスキー(Google Workspace)
- パスワードを使わず、デバイスの生体認証(指紋/顔)や画面ロック PIN に紐づく暗号鍵ペアで本人確認するフィッシング耐性の高い認証方式。Google Workspace 管理者は組織部門(OU)単位でパスキーの利用を許可・必須化でき、2 段階認証プロセス(2SV)の一方式として設定する。
- パススルー認証(PTA)/シームレス SSO
- PTA は認証検証をオンプレエージェントで行いパスワードをクラウドに保存しない方式。シームレス SSO は社内ネットワークの参加 PC で追加プロンプトなしにサインインさせる。クラウドで認証する最も単純な PHS と対比。
- パスワードポリシー
- アカウント全体の IAM ユーザーパスワードに適用する規則。最小文字数・大小英数記号の要求・有効期限・過去パスワードの再利用禁止などを強制でき、アクセスキーの定期ローテーションと合わせて認証情報の衛生を保つ。
- パスワードリスト攻撃
- 他サービスから流出した実在のID・パスワードの組をそのまま別サービスへ試すことで、使い回している利用者のアカウントに不正ログインする攻撃。多数のIPから低頻度で試行されるのが特徴。多要素認証とパスワード使い回しの回避が有効な対策。
- パスワード攻撃(総当たり・辞書・リスト型)
- 他人のパスワードを不正に割り出す攻撃の総称。総当たり攻撃(ブルートフォース)は考えられる文字の組み合わせを片端から試す。辞書攻撃は辞書に載る単語やよく使われる文字列を優先して試す。パスワードリスト攻撃は他サービスから流出したIDとパスワードの組を使い回している利用者に対して試す。長く複雑なパスワード・使い回しの回避・多要素認証・アカウントロックが対策となる。
- パスワード書き戻し(password writeback)
- SSPR でクラウド側にリセットしたパスワードをオンプレ AD に反映する仕組み。Connect Sync で構成する。
- バックアップ
- データの破損・消失や機器の故障に備えて、データの複製を別の場所や媒体に保存しておくこと。障害が起きても、保存しておいた複製から復旧(リストア)できる。定期的に取得し、原本とは別の場所に保管することが重要とされる。
- バックアップ戦略(フル・差分・増分・3-2-1ルール)
- フルバックアップは全データを毎回複製する方式で復旧は最速だが取得に時間・容量を要する。差分バックアップは直近のフルバックアップ以降の変更分のみを複製し、増分バックアップは直前のバックアップ(フルまたは増分)以降の変更分のみを複製するため取得は速いが復旧手順が複雑になる。3-2-1ルールは、データを3つ(原本+複製2つ)保持し、2種類以上の異なる媒体に保存し、そのうち1つは遠隔地(オフサイト)に置くという原則で、ランサムウェア対策としてオフライン保管も重視される。
- バックプレッシャー
- 下流のコンポーネントが処理しきれない量のデータを受け取ったとき、上流へ「送信を遅らせてほしい」という信号を返して流入を抑える仕組み。メッセージキューやストリーム処理パイプラインで、詰まりによるメモリ枯渇や障害の連鎖を防ぐために使う。
- パッケージグループ
- インストール時に用途別にまとめて選択できるパッケージの束(例:サーバー用途の最小構成、デスクトップ環境)。後から単位で追加もできる。
- パッケージとリポジトリ
- Linux のソフトウェアは、配布サーバー(リポジトリ)から取り寄せるパッケージ単位で管理する。パッケージ管理ツールが依存関係を自動解決し、インストール・更新・削除を一元的に扱う。手元の索引(パッケージカタログ)を基準に動く。
- ハッシュ
- 元に戻せない一方向の変換。パスワード保存や改ざん検知に使う(暗号化と異なり復号できない)。
- ハッシュインデックス
- キー値をハッシュ関数で変換した値をもとに格納位置を決めるインデックス方式。等値検索(=)は非常に高速だが、範囲検索やソートには利用できない点が B木インデックスとの主な違い。
- ハッシュ関数(改ざん検知)
- 任意長のデータから固定長の値(ハッシュ値)を算出する関数。同じ入力からは常に同じ値が得られ、わずかな変更でも値が大きく変わるため、データの改ざん検知やパスワードの保管に利用される。
- ハッシュ結合
- 小さい方のテーブルの結合列からハッシュ表をメモリ上に作り、大きい方のテーブルを走査しながらハッシュ表と照合していく結合アルゴリズム。等値結合に限られるが、ソート済みでない大規模データ同士の結合で高速。
- ハッシュ法
- キーをハッシュ関数で変換した値を配列の格納位置とすることで、平均的にO(1)での検索・挿入を実現するデータ構造の手法。異なるキーが同じ格納位置になる衝突(コリジョン)への対処が必要になる。
- バッチエンドポイント
- 大量データをコンピューティングクラスター上で非同期にスコアリングするエンドポイント。呼び出すとバッチスコアリングジョブが起動する。
- パッチグループ(Patch group)
- 「Patch Group」タグの値でインスタンスを分類し、パッチベースラインの適用範囲を区分する仕組み。本番と検証環境で異なるパッチベースライン(承認の待機日数など)を割り当てたい場合に使う、パッチ適用の運用単位。
- パッチコンプライアンス(Patch compliance)
- Patch Manager がスキャンまたはインストールを実行した後、パッチベースラインの承認ルールに対する各インスタンスの準拠状況を集計する機能。未適用パッチがあるインスタンスを可視化し、Compliance ダッシュボードや Config ルールと連携して是正対象を洗い出す。
- バッチ処理
- データをまとめてスケジュールで処理する方式。遅延は許容、大量データを効率よく扱う。例:夜間集計。
- バッファオーバーフローとC2(コマンドアンドコントロール)
- バッファオーバーフローは確保された領域を超えてデータを書き込ませ、隣接するメモリを破壊・上書きしてプログラムを異常動作させたり任意コードを実行させたりする攻撃。C2(コマンドアンドコントロール)は感染端末が外部の攻撃者サーバーと通信し、遠隔から指令を受け取ったり窃取データを送信したりする侵害後の通信経路。
- ハニーポット
- あえて脆弱に見せかけたおとりのシステムを設置し、攻撃者を誘い込むことで攻撃の手口・使用ツール・侵入経路を観察・分析するための仕組み。本番システムへの実害を出さずに攻撃情報を収集できる。
- ハブスポークネットワークトポロジ
- 中央ハブ VNet に共有サービス(ファイアウォール・ゲートウェイ・DNS)を集約し、スポーク VNet をピアリングで接続する設計。Virtual WAN でマネージドに実現することもできる。
- ハフマン符号
- 出現頻度の高い記号には短い符号語、出現頻度の低い記号には長い符号語を割り当てることで、データ全体の平均符号長を最小化する可変長符号化方式。どの符号語も他の符号語の接頭辞にならない(接頭符号)ため、復号時に区切りを一意に判別できる。エントロピー符号化の代表例で、可逆圧縮に用いられる。
- パブリック IP プレフィックス
- 連続したパブリック IP の範囲を予約する仕組み。ファイアウォール許可リストを安定させ、独自の IP 範囲を持ち込む(BYOIP)こともできる。
- パブリック IPv4 アドレスの挙動
- 自動割り当てされる標準のパブリック IPv4 アドレスは動的で、インスタンスの停止・再起動のたびに変わりうる。固定したい場合は付け替え可能な Elastic IP を別途割り当てる必要がある(Elastic IP 自体は別ノードの概念)。
- パブリック/プライベートサブネット
- パブリックサブネット=ルートテーブルにインターネットゲートウェイ(IGW)への経路があり、外部と直接通信できる。プライベートサブネット=IGW 経路を持たず、外向き通信は NAT ゲートウェイ経由。公開する物だけをパブリックに置くのが基本。
- パブリッククラウド
- プロバイダーが所有・運用する共有のクラウド(例:Azure)。初期投資なしですぐ使える。
- ハミング符号
- データビットに複数の検査ビットを付加し、1ビット誤りを自動訂正できる誤り訂正符号。各検査ビットのパリティ検査結果(合致/不一致)の組合せ=シンドロームから誤りビット位置を特定して訂正する。基本のハミング符号は1ビット訂正のみだが、全体パリティビットを1つ加えた拡張ハミング符号(SECDED)は1ビット訂正+2ビット検出が可能。検出のみのパリティチェック単体との違いである。
- パラレルクエリ(max_worker_processes/max_parallel_workers_per_gather)
- 複数プロセスでクエリ処理を分担する仕組み。max_worker_processes はサーバ全体で使えるバックグラウンドワーカー総数の上限、max_parallel_workers_per_gather は1つのクエリが同時に使えるパラレルワーカー数の上限を定める。
- バリアフリー
- 高齢者や障がいのある人にとって障壁(バリア)となる要素を取り除き、利用しやすくする考え方。最初から多くの人が使えるよう設計するユニバーサルデザインと異なり、特定の利用者が抱える障壁を後から解消する点に重点がある。
- パリティビット
- データの1の個数の偶奇を揃えるために付加する検査用の1ビット。偶数パリティは1の総数を偶数に、奇数パリティは奇数に揃える。奇数個のビット誤りを検出できるが誤り位置の特定や訂正はできず、偶数個の誤りは検出できない限界がある。
- バリューチェーン(価値連鎖)
- 企業の事業活動を購買・製造・出荷・販売・サービスなどの主活動と、人事・調達・技術開発などの支援活動に分解し、どの活動が付加価値を生んでいるかを分析するフレームワーク。
- バルクヘッド(隔壁)
- リソースを区画に分離し、1 区画の過負荷や障害が他へ波及しないようにするパターン(船の防水隔壁が由来)。コネクションプールやスレッド、キュー、アカウント/セルを分けて影響を封じ込める。
- ハルシネーション
- 生成AIが「もっともらしいが誤った内容」を自信ありげに生成する現象。人の確認やRAGで緩和。
- パレート図
- 不良や問題の発生要因を発生頻度の高い順に棒グラフで並べ、累積比率を折れ線で重ねた図。少数の要因が大部分の問題を占めるという経験則(80対20の法則)に基づき、優先的に対処すべき要因を絞り込む分析ツールとして重要。
- ハンティンググラフ
- Microsoft Defender の高度なハンティング(advanced hunting)に含まれる公式機能「Hunting graph(ハンティンググラフ)」。エンティティ(デバイス・ユーザー・IPアドレス等)とその関係性をノードとエッジで可視化し、脅威シナリオをインタラクティブなグラフとして表示することで攻撃の連鎖を辿りやすくする。KQL クエリの結果を可視化する補助機能で、侵害の広がりを人手で追跡しやすくする。
- ヒープソートとヒープ条件
- ヒープ条件とは、完全2分木において親ノードの値が常に子ノードの値以上(最大ヒープ)または以下(最小ヒープ)である性質を指す。ヒープソートはこの性質を利用し、配列をヒープに構築してから根(最大値または最小値)を順次取り出して整列済み配列を作るアルゴリズムで、最悪計算量もO(n log n)を保証し追加のメモリ領域をほぼ必要としない点がクイックソートと異なる。
- ピクトグラム
- 文字を使わず、単純な絵記号で情報や案内を伝える表示。非常口やトイレの案内などが代表例で、言語の違いを超えて直感的に理解できる利点がある。多くの人にわかりやすくする情報デザインの手法の一つ。
- ビジネスプロセスフロー
- モデル駆動型アプリで、ユーザーをステージごとの入力手順に沿って案内する仕組み。営業案件の段階管理などに使う(フロー自動化の Power Automate とは別物)。
- ビジネスメール詐欺(BEC)
- 取引先や経営者になりすましたメールを送り、偽の口座への送金や機密情報の提供をだまし取る詐欺手法。マルウェアを使わず、業務プロセスの隙や心理的な緊急性を悪用する点がフィッシングと似るが標的型で狙う相手が限定される。振込先変更時の複数人承認・電話確認などが対策。
- ビジネスモデルキャンバス
- 顧客セグメント・価値提案・チャネル・顧客との関係・収益の流れ・主要資源・主要活動・キーパートナー・コスト構造という9つの要素を1枚のシートに整理し、ビジネスモデル全体を俯瞰・議論するためのフレームワーク。ストラテジストは、新規事業の立ち上げや既存事業の見直しにおいて、要素間の整合性(例えば価値提案とコスト構造が釣り合っているか)を素早く検証し、関係者間で共通言語として議論するために用いる。
- ビジネスルール
- Dataverse 上でコードなしに、必須化・既定値・値の検証・フィールドの表示/非表示などのロジックを適用する仕組み。フォームに依存せずテーブルレベルで効く。
- ビジネスルール(Power Platform)
- コードを書かずにフォームで表示/必須/簡易検証を行うノーコードのロジック。plug-in(サーバー)や client scripting(コード)の代替ではない。
- ビジュアルクエリエディター
- コードを書かずにドラッグ操作で抽出・絞り込み・集計を組み立てる Fabric のクエリ作成画面。裏で SQL を生成する。
- ビジュアルのパーソナライズ(Personalize visuals)
- 閲覧者が自分用にビジュアルの種類/フィールドを変更できる機能(元のレポートは変えない)。リアルタイム更新の自動ページ更新とは別。
- ビジュアル計算(visual calculations)
- ビジュアルの表示結果(可視の行/列)に対して DAX で計算する機能。実行累計や構成比などをモデルにメジャーを増やさずビジュアル内で表現できる。
- ビットマップインデックス
- 列の各取りうる値ごとにビット列(該当行なら1)を持つインデックス方式。性別や都道府県のような値の種類(カーディナリティ)が少ない列に強く、AND/OR 条件をビット演算で高速に評価できる分析系クエリに向く。更新頻度の高い列には不向き。
- ヒット率とアクセス時間(実効アクセス時間)
- ヒット率は、CPUが必要とするデータがキャッシュメモリ上に存在する割合。存在しない割合をミスヒット率(=1−ヒット率)という。実効アクセス時間は「ヒット率×キャッシュのアクセス時間+ミスヒット率×主記憶のアクセス時間」で求められ、ヒット率が高いほど平均アクセス時間が短くなり処理が高速化する。
- ピボット解除(unpivot)
- 横持ちの列を縦持ちの属性/値のペアに変換する Power Query 操作。多くの分析は縦持ちが扱いやすい。ピボットは逆操作。
- ビュー
- テーブルのレコード一覧の定義。表示する列・並び順・フィルター条件を決める。モデル駆動型アプリの一覧画面で使う。
- ビュー(Warehouse)
- ウェアハウスで保存された SELECT 文を、あたかもテーブルのように再利用できるオブジェクト。複雑な結合や集計をビューとして隠蔽し、下流のレポートやクエリを簡潔にする。ビュー自体はデータを複製せず、参照のたびに元テーブルを再評価する。
- ビューとマテリアライズドビュー
- ビューは問い合わせ定義に名前を付けたもので、参照のたびに元の表から再計算され、結果自体は保存しない。マテリアライズドビューは問い合わせ結果を物理的に保存し、REFRESH で明示的に更新するまで元の表への変更を反映しない点が異なる。
- ヒューマンインタフェース
- 人と機械(コンピュータ)との間で情報をやり取りする接点や、その設計技術の総称。画面表示のGUI、音声UI、ジェスチャ操作などを含み、利用者が誤りなく直感的に操作できることを目指す。
- ヒューマンリソース管理
- 企業が従業員という「人材」を効果的に活かすための管理活動です。採用・配置・教育・評価・報酬などを通じて、社員の能力を高め、組織全体の成果につなげることを目的とします。
- ビルド権限(Build)
- 他の作成者が公開済みセマンティックモデルを使って新しいレポートを作るために必要な権限。ビューアーでは再利用できない。
- ビン化(Power BI)
- 数値や日付のフィールドを一定幅または任意の境界で手動の区間(ビン)に区切る Power BI/Power Query の分析機能。年齢層や価格帯のような集計用カテゴリを作るのに使い、区切り方はユーザーが明示的に指定する。似たデータ点を自動でグループ化するクラスタリングとは対照的に、境界を人が決める点が特徴。
- ファイアウォール
- 通信を許可・拒否のルールに従って制御する仕組み。Linux では iptables/firewalld で実現し、クラウド環境ではセキュリティグループなどとして提供される。
- ファイアウォール ポリシー(Intune)
- デバイスの受信/送信トラフィックをルールで制御する Endpoint security のポリシー種別。Windows Defender ファイアウォールの設定(プロファイル別のオン/オフ、規則、通知抑制)を Intune から一括配布し、特定ポートやアプリの通信を許可/拒否する。App Control がアプリ実行そのものを制限するのに対し、こちらはネットワーク通信を制限する。
- ファイアウォールの方式(パケットフィルタ型/アプリケーションゲートウェイ型)
- パケットフィルタ型は送信元・宛先IPアドレスとポート番号など(トランスポート層まで)でパケットごとに許可・拒否を判定する最も基本的な方式。アプリケーションゲートウェイ型(プロキシ型)はアプリケーション層のプロトコルを解釈し、通信を一旦終端・代理中継することでコマンドやデータの内容まで検査できるが、対応プロトコルごとに専用の処理が必要で処理負荷も高い。動的にセッション状態を記憶するステートフルインスペクションはこれらとは別方式。
- ファイアウォールポリシーと Firewall Manager
- ファイアウォールポリシー=規則・脅威インテリジェンス等をまとめた再利用可能な構成。Firewall Manager=複数のファイアウォール/Secured Hub にポリシーを一元適用する。
- ファイアウォールルール(VPC firewall rules)
- VPC 内外のトラフィックを許可/拒否するステートフルな規則。方向・優先度・ターゲット(タグ/サービスアカウント)・送信元で評価する。組織レベルの階層型ファイアウォールポリシーもある。
- ファイアウォール規則(サーバー/データベース)
- Azure SQL への接続元 IP を制御する規則。サーバーレベル規則は論理サーバー全体に、データベースレベル規則は個々の DB に適用する。
- ファイルシステムと mkfs
- パーティションを使える状態にする(フォーマットする)のがファイルシステム作成。mkfs 系で作る。ext4 は Linux の標準汎用(前身 ext3)、XFS は大容量・並列に強い(RHEL 標準)、VFAT は Windows と共用、Btrfs は新世代、tmpfs はメモリ上で再起動で消える。
- ファイルシステムのマウント(/etc/fstab)
- ファイルシステムをディレクトリツリー上の場所(マウントポイント)に取り付けるのがマウント。mount/umount で操作し、使用中は umount できない。ブート時の自動マウントは /etc/fstab に定義し(デバイス・ポイント・種別・オプション・dump・fsck順)、mount -a で検証する。リムーバブルは /media 配下。
- ファイルシステムレベルバックアップ
- データディレクトリ全体をファイルシステムのコピーとして取得するバックアップ方式。サーバ停止中の単純コピーか、稼働中に行う低レベルバックアップ(PostgreSQL 15 以降は pg_backup_start()/pg_backup_stop()、pg_basebackup による)のいずれかで実施する。
- ファイルストレージ
- 共有ファイルシステムとして複数のクライアントから同時にアクセスできるストレージ(EFS・FSx)。ディレクトリ階層でファイルを扱う。
- ファイルパス(絶対パスと相対パス)
- 絶対パスはルート(最上位)から目的のファイルまでの完全な経路を示す表記。相対パスは現在の作業位置(カレントディレクトリ)を起点にした経路の表記。同じファイルでも起点が変わると相対パスの表記は変わる。
- ファイルレスマルウェア
- ディスク上に実行ファイルを残さず、PowerShellやWMIなど正規のシステムツールのメモリ上でコードを展開・実行するマルウェア。シグネチャ(ファイルのハッシュ・パターン)に依存する検知を回避しやすく、挙動監視(ビヘイビア法)での検知が有効となる。
- ファイル権限
- OSがファイルやフォルダごとに設定する、誰が読み取り・書き込み・実行できるかを定める権限。Windowsではユーザー/グループ単位のNTFS ACL、Linuxでは所有者・グループ・その他に対するread/write/execute(rwx)の3種で表す。
- ファインチューニング
- 自社のラベル付きデータで基盤モデルを追加学習し、振る舞い・文体・専門知識を重みに内在化させる方法。RAGより手間大。
- ファインチューニングジョブ
- 基盤モデルを独自データで追加学習し特定タスクに適応させるジョブ。データ準備・適切なベースモデル選択・学習・評価の手順で進める。
- ファインチューニングと合成データの運用
- プロンプト→RAG→ファインチューニングの順(コスト/効果)で最適化する。ファインチューニングは高品質な学習データが要で、不足時は合成データを作成(品質・多様性・偏りの管理が必要)。ファインチューニング済みモデルも過剰適合や劣化を監視し、評価→登録→デプロイ→監視の MLOps ライフサイクルで開発から本番まで管理する。
- ファクトテーブル
- 売上や数量などの数値(メジャー)と、各ディメンションへの外部キーを持つ中心テーブル。1 行が表す単位=粒度をまず決める。
- ファクト表とディメンション表
- データウェアハウスのスタースキーマを構成する2種類の表。ファクト表は売上数量・金額などの数値的な実績データを格納し、ディメンション表は「いつ」「誰が」「どの商品」といった分析の切り口となる属性データを格納する。
- ファシリティマネジメント(UPS・免震・耐震)
- データセンター等の建物・電源・空調といった物理的な設備を最適に維持・管理する活動。UPS(無停電電源装置)は停電時に一定時間電力を供給し、非常用発電機への切替や安全なシャットダウンまでの橋渡しをする装置。免震構造は建物と地盤の間で揺れを吸収して地震の揺れを建物に伝えにくくする方式、耐震構造は建物自体を頑丈にして揺れに耐える方式で、揺れの伝わり方が異なる。
- ファストトラッキング
- 通常は順番に行うアクティビティを並行して実施することでスケジュールを短縮する技法。追加コストはかからないが、手戻りやリスクが増大する可能性があるため、クラッシングとのトレードオフ(コスト増 vs リスク増)を踏まえて選択すべき点が重要。
- ファンクションポイント法
- システムが持つ画面や帳票・データファイルなどの機能の数と難易度から、開発規模や工数を見積もる手法。プログラムの行数(LOC)に頼らず、利用者視点の機能量で見積もれる点が特徴。
- ファントムリード
- 同一トランザクション内で同じ条件の範囲検索を2度行った際、間に別のトランザクションが行を挿入・削除したために結果件数が変わってしまう読取り異常。SQL標準では REPEATABLE READ までは発生しうるとされ、SERIALIZABLE で防止される(ただしPostgreSQLのMVCCやMySQL InnoDBのギャップロックなど、実装によってはREPEATABLE READでも防止される)。
- フィーチャーストア
- 特徴量を定義・計算・共有・再利用する仕組み。学習と推論で同じ特徴量を取得し、整合性(トレーニング/サービングスキュー回避)を保つ。
- フィーチャーフラグ
- デプロイ(コードを本番に置く)と機能の有効化(リリース)を分離する仕組み。Azure App Configuration の Feature Manager 等で管理し、段階公開・A/B テスト・即時無効化(キルスイッチ)を再デプロイなしで行える。
- フィールドパラメーター
- レポート利用者が表示するメジャーや軸を動的に切り替えられるようにする機能。1 つのビジュアルで複数の見方を提供する。
- フィールドレベル暗号化
- CloudFront のエッジで特定フォームフィールド(クレジットカード番号など)を公開鍵で暗号化し、オリジンまで秘匿したまま運ぶ機能。アプリ側は対応する秘密鍵を持つ最終処理点でのみ復号する。
- フィジビリティスタディ(実現可能性分析)
- システム化構想・企画段階で、技術面・コスト面・スケジュール面・組織面などの観点から、当該プロジェクトが実現可能かどうかを事前に検証する分析。実施の結果、実現困難な要因(リスク)が判明した場合は、計画の見直しや代替案の検討、あるいは中止の判断につなげる。共通フレームの企画プロセスにおいて、システム化計画の立案と並行して行われることが多い。
- フィッシング
- 実在する企業や金融機関になりすました偽のメールやWebサイトへ誘導し、ID・パスワードやクレジットカード情報などを盗み取る詐欺の手口。URLやドメインをよく確認することが対策の基本。
- フィルタ(テキスト処理コマンド)
- 標準入力を加工して標準出力へ流す単機能コマンド群。閲覧 cat/less(ページャ)/head/tail(-f で追記監視)、変換 tr/nl、結合 paste/join、分割 split、整形 expand/unexpand/fmt/pr、バイナリ表示 od。パイプで組み合わせて使う。
- フィルターコンテキストと行コンテキスト
- DAX 評価の 2 つの文脈。行コンテキスト=現在の行、フィルターコンテキスト=適用中の絞り込み。CALCULATE はフィルターコンテキストを操作する。
- フィンテック(FinTech)
- Finance(金融)とTechnology(技術)を組み合わせた造語。スマートフォン決済・仮想通貨・ロボアドバイザーなど、ITを活用した新しい金融サービスの総称。
- ブートストラップ(初期起動処理)
- インスタンスの初回起動時に初期設定(パッケージ導入・構成取得・サービス起動)を自動実行すること。EC2 ではユーザーデータスクリプトで行い、cloud-init が処理する。
- ブートローダ
- 電源投入・リセット直後に最初に実行される小さなプログラムで、最低限のハードウェア初期化を行った後、フラッシュメモリ等に格納された本体ファームウェアをメモリへロードして実行を開始させる役割を担う。OTA更新の際は新旧ファームウェアの切替や書込み失敗時のロールバックを担うことも多く、機器の信頼性に直結する。
- ブートローダー(GRUB2)
- ファームウェアの後にカーネルを選択・読み込むプログラム。Linux の標準は GRUB2 で、カーネルとブートオプションをメニューで選べる。
- フェイルオーバークラスターインスタンス(FCI)
- 共有ストレージ上で SQL Server インスタンス全体を複数ノードでクラスター化し、ノード障害時に自動フェイルオーバーするインスタンスレベルの HA。
- フェイルオーバーグループ
- 複数 DB をグループ単位でリスナー越しに接続し、接続文字列を変えずに自動フェイルオーバーさせる DR 機能。
- フェイルオーバー訓練(DR ドリル)
- HA/DR 構成がいざという時に機能するかを実地検証する定期的な訓練。フェイルオーバー後の接続復旧・整合性・ダウンタイムが目標(RTO/RPO)内かを計測する。未検証の HA は信用できない。
- フェーズゲート
- プロジェクトの各フェーズの終了時に設定される審査点で、成果物や状況をレビューし次フェーズへの移行可否(継続・修正・中止)を判断する仕組み。段階的に投資判断を見直せる点で、大規模プロジェクトのリスク統制上重要。
- フェールオーバーとフェールバック
- フェールオーバーは主系に障害が生じたとき、処理を自動的に待機系へ切り替えて可用性を維持する仕組み・動作を指す。フェールバックは主系が復旧した後、待機系で継続していた処理を本来の主系へ戻すことをいう。システムアーキテクトはフェールオーバー時のデータ整合性やセッション引継ぎ、フェールバック時の再切替に伴う瞬断を設計上考慮する。
- フェールセーフ/フェールソフト
- 故障発生時の2つの設計思想。フェールセーフは、システムを機能停止させてでも安全な状態へ確実に移行させる(信号機の故障時に全灯赤にする、電車の制動失陥で自動ブレーキがかかるデッドマン方式等)、可用性より安全性を優先する考え方。フェールソフトは、システム全体を止めず故障箇所を切り離して機能を縮退させながら運転を継続させる、サービス継続性を重視する考え方で、冗長構成を持つシステムで採用されやすい。
- フェデレーション資格情報(workload identity federation)
- クライアントシークレットや証明書を保存せずに、外部 IdP(GitHub Actions 等)のトークンを信頼してアプリを認証する仕組み。CI/CD パイプラインからの鍵レス認証に最適。
- フォーク PR の実行承認
- 外部のフォークからの PR で初めて Actions を動かす際に承認を必須にする設定。外部コードの無確認実行やシークレット悪用を防ぐ。
- フォーム
- 1 件のレコードを表示・入力・編集する画面部品。モデル駆動型アプリではテーブルごとにフォームを定義し、表示するフィールドや配置を設定する。
- フォーム操作関数(SubmitForm・NewForm・EditForm)
- フォームコントロールを操作する関数。SubmitForm で入力を保存、NewForm で新規作成、EditForm で編集モードに切り替える。
- フォールトトレランス(耐障害性)
- 構成要素が壊れてもサービスを止めない設計。高可用性(早期復旧)より一段強く、障害時も中断なく稼働し続ける。冗長な並行系(アクティブ/アクティブ)・N+1 構成・複数 AZ への分散で実現する(自動復旧は中断を伴うため高可用性側の手段)。
- フォルダー/ファイルレベルのアクセス制御
- OneLake セキュリティ(データアクセスロール)で、テーブルやフォルダー単位に読み取り/読み書きを付与する RBAC。既定は拒否で、権限は下位フォルダーに継承される。
- フォローアップ
- システム監査で指摘した事項について、被監査部門がどの程度改善したかを後日確認する活動。監査人は被監査部門からの改善報告を鵜呑みにせず、実際の証跡や運用状況といった監査証拠に基づいて改善の実効性を検証する必要がある。
- フォワードプロキシ
- クライアント側に立ち、クライアントに代わって外部サーバーへリクエストを送るプロキシ。クライアントの匿名化や、組織内からの通信の集中管理・フィルタリングに使う。リバースプロキシ(サーバー側で使う)とは逆方向。
- ブックマーク(Power BI)
- 現在の状態(フィルター/表示/並び)を保存し、ボタンと組み合わせて切替やプレゼン、選択ペインでの Show/Hide を作る機能。
- プッシュ型/プル型コミュニケーション
- プッシュ型は送信者が特定の受信者へ能動的に情報を送る方式(メール・報告書配布など)、プル型は受信者が必要なときに自ら情報を取得する方式(社内ポータルの公開資料など)。情報の緊急性・対象範囲に応じてどちらを使うべきか使い分ける判断が重要。
- フュージョンチーム(プロ開発者との協働)
- 市民開発者とプロの開発者が協働し、ローコードと本格コード(Azure・カスタムコネクタ・PCF コンポーネント等)を組み合わせて作るチーム体制。
- プライベート DNS ゾーン
- VNet 内だけで有効な DNS ゾーン。VNet にリンクして内部名や privatelink 名をプライベート IP に解決する。プライベートエンドポイント運用の要。
- プライベート IP アドレス範囲(RFC1918)
- インターネットでルーティングされない私設アドレス帯:10.0.0.0/8・172.16.0.0/12・192.168.0.0/16。VPC の CIDR はこの範囲から選ぶのが基本。複数 VPC を接続する際は範囲の重複を避ける(重複するとピアリング/TGW で到達不能)。
- プライベート/パブリック IP アドレス
- プライベート IP アドレス(10.0.0.0/8・172.16.0.0/12・192.168.0.0/16)は組織内などの限られた範囲でのみ使う番号で、そのままではインターネットに直接出られない。インターネット上で一意に到達可能なパブリック IP アドレスと対になる区分で、ルータ等で相互に変換して通信する。
- プライベートアドレス
- RFC 1918で定義された組織内ネットワークでのみ使用するIPv4アドレス空間(10.0.0.0/8、172.16.0.0/12、192.168.0.0/16)。インターネット上ではルーティングされず、外部通信にはNAPTによるグローバルアドレスへの変換が必要となる。
- プライベートエンドポイント
- PaaS(Storage/SQL 等)へ VNet 内のプライベート IP を持つ NIC を通じて公開経路を使わず接続する仕組み。サブリソースごとにエンドポイントと DNS ゾーンが要る。
- プライベートクラウド
- 単一組織専用のクラウド。自社や専用ホスト先に構築し、管理を自社で握る。
- プライマリメトリック
- スイープや AutoML が最適化の良し悪しを判断する指標(例:accuracy・AUC)。最大化/最小化の方向も指定する。
- ブラストラディウス(影響範囲)
- 障害や誤操作・侵害が及ぶ影響範囲。アカウント分離・複数リージョン/AZ・最小特権・セル分割で範囲を小さく保つ。範囲を限定する設計が回復力とセキュリティの基本。
- ブラックボックステスト
- プログラムの内部構造は考慮せず、入力に対して仕様どおりの出力が得られるかを外部から検証するテスト手法。同値分割や限界値分析といったテストケース設計技法を用いる。
- フラッディング
- L2スイッチが宛先MACアドレスをMACアドレステーブルに保持していない場合や、宛先がブロードキャスト・マルチキャストアドレスの場合に、受信ポートを除く全ポートへフレームを送出する動作を指す。未学習の宛先解決に有効な反面、多用されると帯域を圧迫し、ループ構成下ではブロードキャストストームの原因にもなる。
- フラット L2 ネットワーク(Docker)
- Docker の既定のブリッジネットワークで、同一ホスト上のコンテナ同士が単一のレイヤー2セグメントに接続され、直接通信できる構成。ルーティングを介さずシンプルにコンテナ間通信ができる反面、大規模環境ではセグメント分割が必要になる。
- プラットフォームビジネス(両面市場・ネットワーク効果)
- プラットフォーム事業者が売り手と買い手など異なる利用者グループを仲介し、双方の便益を最大化するビジネスモデル。片方の利用者が増えるほど他方にとっての価値も高まる「ネットワーク効果」が働き、先行者が優位に立ちやすい。ITストラテジストは自社が単なる製品提供者に留まらず、多数の参加者をつなぐ場(プラットフォーム)へ転換できないかを、事業変革の選択肢として検討する。
- ブランチ
- 並行した開発ラインを表す動く参照。main などから feature ブランチを切って作業する。
- ブランチ保護ルール
- マージ前に必須レビュー・必須チェック・会話解決などを強制し、直接 push を禁止できる設定。
- ブランド戦略
- 自社の商品・サービスや企業そのものに対する顧客の認知・信頼・愛着(ブランドエクイティ)を高め、価格競争に頼らない差別化と持続的な収益を確立するための戦略。一貫したメッセージや顧客体験の提供によりブランドの価値を積み上げ、他社が模倣しにくい競争優位の源泉とする。ITストラテジストはデジタルチャネルを含む顧客接点全体でブランド体験を一貫させ、ITの活用がブランド価値の向上にどう寄与するかを事業戦略に組み込む。
- プランナ制御パラメータ(enable_*/random_page_cost/hash_mem_multiplier)
- プランナの挙動を診断・制御するパラメータ群。enable_*(例:enable_seqscan)は特定のスキャン/結合方式を一時的に無効化してプランナの判断を検証する調査用スイッチ。random_page_cost はランダムI/Oのコスト見積もりでIndex Scanの有利さに影響(SSD環境では下げることが多い)。hash_mem_multiplier はハッシュ系操作に work_mem の何倍までメモリを許すかを制御する。
- プランナ分布統計(most_common_vals/most_common_freqs/histogram_bounds)
- pg_stats の分布統計。most_common_vals(MCV)は頻出値のリスト、most_common_freqs はそれぞれの出現頻度。histogram_bounds は MCV に含まれない値の分布を表す等頻度ヒストグラムの境界値で、範囲述語(WHERE col > 定数)の選択率推定に使われる。
- フリート(fleet)
- 企業全体の多数の GKE クラスタを一貫したポリシー/構成で横断的に管理する仕組み。クラスタごとの手設定を避け、一元的に統制する。
- フリーフロート
- あるアクティビティが、直後の後続アクティビティの最早開始日に影響を与えることなく遅延できる時間。トータルフロートより小さいか等しく、局所的な遅延の余地を示すため、後続作業への即時影響を判断する際に用いる。
- プリエンプション
- 実行中のタスクよりも優先度の高いタスクが実行可能になった時点で、スケジューラが強制的に実行中タスクを中断し、優先度の高いタスクに切り替える仕組み。緊急性の高い処理への即応性を確保できる一方、切替対象のタスクの実行途中でリソースが不整合な状態のまま中断されないよう、クリティカルセクションの保護設計が必要になる。
- ブリッジテーブル(多対多)
- 多対多の関係を解消するために間に置く中間テーブル。直接の多対多リレーションシップの代わりに使い、集計の二重計上を避ける。
- フリップフロップ
- 1ビットの情報を保持できる順序回路の基本素子。クロック信号に同期して入力を取り込み、次のクロックまで出力を保持する。レジスタやカウンタなど記憶回路の構成要素になる。
- プリンシパル
- IAM においてアクションを実行する主体そのもの(IAM ユーザー・ロール・AWS サービス・別アカウント・フェデレーション ID など)。リソースベースポリシーや信頼ポリシーの Principal 要素で「誰に許可するか」を指定するときの対象になる。
- フリンの分類
- 命令流と データ流の数によりコンピュータアーキテクチャをSISD・SIMD・MISD・MIMDの4種に分類する枠組み。SIMDは1命令で複数データを一括処理(ベクトル演算・GPU等)、MIMDは複数プロセッサが独立に異なる命令とデータを処理する(マルチコア・分散システム)。
- プルアップ抵抗
- 入力ピンを電源電圧側に抵抗を介して接続し、外部から明示的にLowへ引き下げられない限りHighレベルを維持させる回路。オープンドレイン/オープンコレクタ出力のデバイス(I2C等)や、スイッチが開放状態のときの入力レベルを不定にしないために用いられ、値が未確定(フローティング)になることを防ぐ。
- ブルーオーシャン戦略
- 既存の競争が激しい市場(レッドオーシャン)を避け、価値を高めながらコストを下げる「バリューイノベーション」によって、競争のない新たな市場空間を切り開く戦略。ストラテジストは、業界の既存の枠組みで何を取り除き・減らし・増やし・付け加えるかを検討するアクションマトリクスなどを用い、差別化とコストリーダーシップを同時に追求できないかを判断する。
- プレイグラウンド
- デプロイした言語モデルをコードなしで対話的に試し、プロンプトやパラメーターの挙動を確認する場所。
- プレイスメントグループ(クラスター/分散/パーティション)
- インスタンスの物理配置戦略。クラスター=同一ラックに密集し低遅延・高スループット(HPC)。分散(スプレッド)=別ハードウェアに分けて同時障害を回避(少数の重要インスタンス)。パーティション=グループ単位で障害分離(HDFS 等の分散システム)。
- プレシデンスダイアグラム(PDM)
- アクティビティをノード(箱)で表し、矢印で先行関係を示すスケジュールネットワーク図法。ダミーアクティビティが不要でFS/SS/FF/SFの4種の依存関係すべてを直接表現できるため、現代のプロジェクトスケジューリングで標準的に使われる。
- プロアクティブ問題管理
- インシデントが発生する前に潜在的な原因を見つけ出し、除去してインシデントの発生を未然に防ぐ問題管理の側面。過去のインシデント傾向分析や監視データの分析から弱点を特定し、対策を先手で講じる。発生後に反応するリアクティブ問題管理と対をなす。
- フローティングIP
- インスタンスに動的に付け替え可能なパブリック IP アドレス。障害発生時に正常なインスタンスへ素早く付け替えることでフェイルオーバーを実現する。特定インスタンスに固定される固定IPとは対照的。
- フローティングスタティックルート
- 本来使われるプライマリ経路(動的経路や別の静的経路)よりも大きいアドミニストレーティブディスタンスを意図的に設定したバックアップ用の静的経路。平常時は経路表に載らず使われないが、プライマリ経路が消えたときだけ自動的に採用され、簡易なフェイルオーバーを実現する。
- ブロードキャスト
- 同一ネットワークセグメント内の全ホストへ一斉にデータを送る通信方式。多くのパブリッククラウドの仮想ネットワーク(VPC/VNet 相当)は既定でブロードキャストをサポートしないため、オンプレ前提のアプリをそのまま移行しようとすると設計の見直しが必要になる。
- ブロードキャストストーム
- L2ネットワークにループがある状態で、TTLを持たないブロードキャストフレームがスイッチ間を無限に周回・増幅し続け、CPU使用率の急上昇と回線の輻輳でネットワークを機能不全に陥らせる障害。STPによるループ防止で未然に回避できる。
- ブロードキャストドメイン
- ブロードキャストフレームが到達しうる範囲を指し、L2スイッチで接続された同一ネットワーク(同一VLAN)全体が1つのブロードキャストドメインとなる。L2スイッチはコリジョンドメインを分割してもブロードキャストドメインは分割せず、ルータやVLAN分割によってのみブロードキャストドメインは分離される。ブロードキャストドメインが大きいほどブロードキャストストームの影響範囲も広がる。
- フローの種類(自動/インスタント/スケジュール)
- クラウドフローの起点による分類。自動=イベント起点(メール受信など)、インスタント=手動(ボタン)起点、スケジュール=定時起点。
- プロキシサーバー
- クライアントとサーバーの間に立ち、リクエストを中継するサーバーの総称。用途によりフォワードプロキシ(クライアント側)とリバースプロキシ(サーバー側)に分かれる。Squid などが代表的な実装。
- プロキシフィルタリング
- プロンプトがモデルに渡る経路で、有害コンテンツ・脆弱なパターン・(設定により)公開コード一致などをフィルタリングする段階。完全ではない。
- プログラミングパラダイム(手続き型・関数型)
- プログラムの組み立て方に関する基本的な考え方。手続き型は処理の手順(命令の並び)を順に記述していくパラダイム。関数型は計算を「数学の関数の適用」として捉え、外部の状態を変更する副作用を避けるパラダイムで、同じ入力に常に同じ出力を返す純粋関数を組み合わせて構築する。オブジェクト指向と並ぶ代表的な3大パラダイムを成す。
- プログラムマネジメント
- 単一のプロジェクトでは実現できない事業目標の達成に向けて、関連する複数のプロジェクトを束ね、相互の依存関係や資源配分を調整しながら全体最適を図るマネジメント。個々のプロジェクトマネジメントが「決められたことを正しく行う」ことに主眼を置くのに対し、プログラムマネジメントは事業戦略の実現という「正しいことを行う」判断が求められる。ITストラテジストは複数のシステム化案件を一つのプログラムとして統括し、経営目標との整合を継続的に確認する。
- プログラム言語とマークアップ言語
- プログラム言語は、コンピュータに処理手順を指示するための人工言語(C・Java・Pythonなど)。マークアップ言語は、文書の構造や見た目を記号(タグ)で指定する言語で、Webページを記述するHTMLやデータ交換に使うXMLが代表例。処理を書くか、構造を示すかで役割が異なる。
- プロジェクトマネジメントの管理領域
- プロジェクトを計画的に進めるために管理すべき対象を分けて整理したもの。作業範囲を定めるスコープ管理、日程を決めるスケジュール管理、費用を抑えるコスト管理、成果物の水準を保つ品質管理、起こりうる問題に備えるリスク管理、関係者の期待を調整するステークホルダ管理などがある。これらを組み合わせて全体をまとめる。
- プロジェクト憲章
- プロジェクトの存在を正式に認可し、プロジェクトマネージャに資源を使用する権限を付与する文書。目的・概要・前提条件・主要ステークホルダを記載する。プロジェクトの立上げを公式化し、以降の計画の拠り所となる点で重要。
- プロセス/PID
- 実行中のプログラムの単位がプロセスで、一意の番号 PID で識別される。最初に起動する PID 1 は systemd(init)。
- プロセスマイニング(Process Mining)
- 実際の業務システムのイベントログを取り込み、業務プロセスの実態を可視化・分析して、ボトルネックや自動化の機会を見つける Power Automate の機能。
- プロセス監視(top/ps/pstree/uptime)
- 稼働中プロセスと負荷を見るコマンド群。top はリアルタイムの CPU/メモリ上位、ps はスナップショット(ps aux)、pstree は親子ツリー、uptime は稼働時間とロードアベレージ。
- プロセス群
- JIS Q 21500におけるプロジェクトマネジメント活動の5つのグループ(立上げ・計画・実行・監視コントロール・終結)。単純な時系列の段階ではなく、プロジェクト内で重複・反復しうる(例:計画と実行を反復する)。対象群(知識エリア)と組み合わせた行列でどのプロセスがどの知識エリアに属するかを整理する枠組みとして重要。
- プロセス中心アプローチ(POA)
- 業務の処理機能(プロセス)を中心に情報システムを分析・設計する方法論。DFD(データフロー図)などで機能を段階的に分割し、各機能が扱う入出力を定めていく。機能の変化にデータ構造が引きずられやすく保守性で不利になりがちで、データ構造を安定基盤とするデータ中心アプローチ(DOA)と対比される。システムアーキテクトは対象業務の性質に応じて両者を使い分ける判断を行う。
- プロダクトイノベーションとプロセスイノベーション
- プロダクトイノベーションは新しい製品・サービスそのものを生み出す革新、プロセスイノベーションは既存製品を生産・提供する工程・方法を革新して効率やコストを改善することを指す。ストラテジストは、事業の成長初期には差別化のためプロダクトイノベーションを、成熟期にはコスト競争力のためプロセスイノベーションを重視するというように、事業のライフサイクル段階に応じて投資の力点をどちらに置くかを判断する。
- プロダクトオーナーとスクラムマスター
- スクラムチームを構成する3つのアカウンタビリティのうちの2つ。プロダクトオーナーはプロダクトバックログの管理と価値最大化に責任を持ち「何を作るか」を決める。スクラムマスターはスクラムの確立を支援しチームの障害を除去するファシリテーター。残る開発者(Developers)が「どう作るか(実装方法)」を決める。特定の管理者が一方的に指示する構造ではない点が試験での問われどころ。
- プロダクトバックログとスプリントバックログ
- プロダクトバックログは、プロダクトに必要な機能・改善を優先順位付きで並べた一覧で、プロダクトオーナーが管理し常に更新され続ける。スプリントバックログは、そこから当該スプリントで実施する項目を選び出し、実現方法まで開発チームが計画したもの。両者の違いは対象期間(プロダクト全体 vs 1スプリント)と管理主体にある。
- ブロックストレージ
- OS がボリュームとしてマウントして使う低遅延ストレージ(EBS)。データベースや起動ディスク向き。多くは1つのインスタンスに接続して使うが、EBS Multi-Attach など複数インスタンスから同時アタッチできる構成も存在する。
- プロトタイピング
- 開発の早い段階で試作品(プロトタイプ)を作り、利用者に確認してもらうことで要求の妥当性を検証する開発モデル。画面や操作性など言葉では伝わりにくい要求を実物で合意でき、認識のずれや手戻りを早期に減らせる。システムアーキテクトは要求が曖昧で不確実性が高い場面でこの手法を選び、試作の範囲と使い捨てか進化させるかの方針を判断する。
- プロビジョニングログ
- SaaS アプリへの自動プロビジョニング(ユーザーの作成/更新/削除)の結果を記録する Entra ログ。ディレクトリ変更を記録する監査ログ、認証イベントを記録するサインインログとは用途が異なる。
- プロビジョンド vs サーバーレス
- 容量モデルの対比。プロビジョンド=事前に容量を確保(予測可能な負荷・常時稼働で割安なことも)。サーバーレス=需要に自動追従し使った分だけ課金・容量管理不要(断続的/予測困難な負荷向け)。Aurora・DynamoDB・Lambda 等で選択肢になる。
- プロビジョンドスループットの最適化
- Bedrock のプロビジョンドスループット(モデルユニットを予約し安定容量を確保)を無駄なく使う運用。利用率を監視し、ピークに合わせて確保しつつオフピークはオンデマンドへ寄せる。常時高負荷なら割安、散発負荷ならオンデマンドが有利。
- ブロンズ層
- メダリオンの最初の層。ソースから取り込んだ生データを、ほぼそのまま保持する(履歴/再処理の起点)。
- プロンプトエンジニアリング
- 指示・例・役割(システムプロンプト)の与え方を工夫して出力を改善する最も手軽な方法。ゼロショット/少数ショット/思考の連鎖がある。
- プロンプトガバナンス
- プロンプトを資産として統制する運用。Bedrock Prompt Management でテンプレート化・バージョン管理・デプロイ(エイリアス)し、Guardrails で逸脱を抑え、CloudTrail/CloudWatch Logs で API 操作やアクセスを監査する。どのプロンプト版を誰がいつ使ったかを追跡可能にする。
- プロンプトキャッシュ
- 共通の接頭辞(システムプロンプト等)の再計算を省いて、トークンコストとレイテンシを下げるキャッシュ手法。意味的に同一の結果を再利用するセマンティックキャッシュとは異なる。
- プロンプトシールドと有害性検出
- ジェイルブレイクや間接的プロンプトインジェクションを検出するプロンプトシールドと、保護された素材(著作物)の検出で生成 AI の悪用や漏えいを防ぐ。
- プロンプトテンプレート
- 変数を差し込める雛形としてプロンプトを定義し、入力に応じて動的に組み立てる仕組み。再利用と一貫性を高める。
- プロンプトと補完
- プロンプト=モデルへの入力(指示/質問)、補完=モデルが返す生成結果。
- プロンプトの管理
- 管理者やユーザーがよく使うプロンプトを保存・共有・スケジュール・削除して、組織で再利用・標準化する機能。
- プロンプトバリアント
- 同じ目的に対する複数のプロンプト版を定義・追跡し、手動評価や指標で比較して最良の表現を選ぶ手法。
- プロンプトファイル
- 再利用する定型の指示をファイル化し、Chat で一貫した応答を得るための仕組み。常時適用の instructions ファイルとは用途が異なる。
- プロンプトフロー(Foundry)
- LLM・プロンプト・Python・ツールをノードでつないで生成 AI のフローを構築・評価・デプロイする開発機能。RAG やエージェントの実装に使う。
- プロンプトフロー(prompt flow)
- LLM・プロンプト・Python・ツールをノードとして連結し、生成 AI アプリのフローを構築・評価・デプロイする開発ツール。SDK で連鎖ロジックを定義する。
- プロンプトフローの CI/CD
- プロンプトフローをコードとして扱い、評価をゲートにした自動テスト・承認・デプロイのパイプラインを構成して、生成 AI アプリを安全に反復リリースする。
- プロンプト回帰テスト / デプロイ検証
- 生成 AI 変更(プロンプト・モデル・RAG)の品質劣化を防ぐ検証。期待出力との照合・エッジケース・合成フロー・品質ゲートを CI/CD に組み込み、回帰があれば本番投入を止める。A/B・カナリアと組み合わせて段階展開する。
- ペアプログラミング
- 2人の開発者が1台の端末を共有し、一方がコードを書く「ドライバー」、もう一方が設計や誤りを確認する「ナビゲーター」の役割を交代しながら実装を進める手法。エクストリームプログラミング(XP)のプラクティスの一つで、リアルタイムのレビューによる品質向上と知識共有を狙う。
- ベアメタルとコンテナ(配備モデル)
- ベアメタルはハイパーバイザを介さず単一OSがハードウェアを専有する配備方式で、他ワークロードとの共有を前提としないため性能は最高(隔離という軸ではVM/コンテナと同列に比較しにくい)。仮想マシンは独自OSごとハイパーバイザで分離するため隔離が強いが重い。コンテナはホストOSのカーネルを共有しながらプロセスを隔離する中程度の隔離の軽量な方式で、起動が速く移植性も高い。用途に応じて隔離の強さ・軽さ・性能のトレードオフで選ぶ。
- ページ(Power Pages)
- Power Pages サイトを構成する 1 枚の Web ページ。セクションやコンポーネントを置いて内容を作り、ナビゲーションでつなぐ。
- ページネーションされたレポート
- 固定レイアウトで印刷/PDF 向けの帳票型レポート。明細の多い表を複数ページにきれいに分割でき、Power BI Report Builder で作成する。対話的な Power BI レポートとは目的が異なる。
- ページフォールトとスラッシング
- ページフォールトは、仮想記憶で必要なページが主記憶上に無いときに発生する割込みで、補助記憶からのページ読み込み(ページイン)が行われる間、処理が一時停止する。搭載メモリに対して同時に必要なページが多すぎると、ページの入れ替え(ページング)が頻発してCPUがほとんど入出力待ちになり、処理効率が著しく落ちる。この状態をスラッシングという。
- ページ置換アルゴリズム
- 仮想記憶において主記憶が満杯の際にどのページを追い出すかを決定するアルゴリズム。代表例はLRU(最も長く使われていないページを置換)、FIFO(最も古く読み込まれたページを置換)、LFU(使用頻度が最も低いページを置換)。
- べき等な HTTP メソッド
- HTTP メソッドの性質。GET/PUT/DELETE はべき等(何度呼んでも結果が同じ)、POST は非べき等(呼ぶたび作成され得る)。再試行やリトライ設計で重要=べき等な操作は安全に再送でき、非べき等はべき等キーで重複を防ぐ。
- べき等性
- 同じ操作を何度実行しても結果が変わらない性質。分散システムではネットワーク再送やリトライでリクエストが重複しやすく、べき等な設計(べき等キーの利用など)があれば重複配信されても安全に処理できる。
- ベクタ割込み
- 割込み要因ごとにあらかじめ割込みベクタテーブルに登録された専用の処理ルーチンへ、ハードウェアが直接分岐する割込み方式。全要因を1つのハンドラで判定するポーリング型に比べ、要因判定のオーバーヘッドがなく応答が高速なため、リアルタイム性が要求される組込みシステムで用いられる。
- ベクトルストア
- 埋め込みベクトルを保存し近傍検索する基盤。RAG では関連チャンクの検索に使い、Azure AI Search 等をインデックスストアとして構成する。
- ベクトルデータベース
- 埋め込みベクトルを格納し近傍検索する基盤。RAG の検索層に使い、AWS では OpenSearch Service(k-NN)・Aurora/RDS の pgvector・MemoryDB・DocumentDB 等を用いる(Amazon Kendra はベクトル DB でなく別カテゴリのマネージド検索)。
- ペネトレーションテスト
- 実際の攻撃者と同じ手法・視点でシステムへの侵入を試み、発見した脆弱性が実際に悪用可能で、どこまで被害が広がりうるかを実証するテスト。網羅的に弱点を洗い出す脆弱性診断に対し、特定の侵入経路を深掘りする点が異なる。
- ヘルスチェック
- ロードバランサや冗長化構成において、配下のサーバや機器が正常に応答可能かを定期的に確認する仕組み。TCP接続確立の可否を見るL4ヘルスチェックと、HTTPリクエストを送信しステータスコードや応答内容まで検証するL7ヘルスチェックがあり、異常検知した対象は振り分け・切替の対象から自動的に除外される。
- ヘルスチェック(liveness / readiness)と HPA
- liveness プローブは異常な Pod を再起動し、readiness プローブは準備完了までトラフィックを送らない。Horizontal Pod Autoscaler(HPA)は負荷に応じて Pod 数をスケールする(ノード数は Cluster Autoscaler)。
- ヘルスチェックの種類としきい値
- 正常性判定の設計。浅いチェック(プロセス生存)と深いチェック(依存先含む実機能)。正常しきい値/異常しきい値=連続成功/失敗回数で状態を確定しフラッピングを抑える。間隔とタイムアウトも調整。ELB・Route 53・Auto Scaling で使う。
- ベロシティ
- アジャイル開発において、1スプリントあたりにチームが完了できる作業量(ストーリーポイントなど)の平均的な実績値。過去のスプリントの実績から算出し、以降のスプリント計画やリリース予測の見積り根拠として使う点で重要。
- ベンダーロックイン
- 特定ベンダーの製品/形式への依存が強く、他へ移行しにくくなる状態。標準やデータポータビリティで緩和する。
- ベンチマーク
- 標準化された負荷やテストプログラムを用いてシステムやコンポーネントの性能を定量的に測定・比較する手法、またはその指標。TPC系(トランザクション処理)やSPEC系(CPU・演算)などがあり、同一条件で機器や構成の性能差を評価できる。システムアーキテクトは製品選定や構成検証の根拠としてベンチマーク結果を用いるが、自システムの実負荷特性との差異に注意する。
- ボイスコッド正規形(BCNF)
- 第3正規形をさらに厳格化した正規形。「全ての自明でない関数従属の決定子が候補キーである」ことを要件とし、第3正規形では残ってしまう一部の更新時異常(候補キーが複数ある場合の異常)まで除去する。
- ボイスメール ポリシー(voicemail policies)
- 留守番電話の動作を制御するポリシー。ボイスメールの有効/無効、転送先のメールアドレス、既定/カスタムの応答メッセージ、文字起こしの有効化などを設定する。通話機能全般を制御する calling policies とは対象が異なる(留守電のみ)。
- ポイントツーポイント(VPN 接続形態)
- VPN で1台のクライアントと1つの拠点(またはサーバー)を1対1で接続する形態。複数拠点同士を結ぶサイトツーサイトとは異なる。OpenVPN 等で構成する。
- ポイント操作とクエリ操作
- ポイント操作は id+パーティションキーで 1 件を read/create/replace/upsert/delete し、最も安く速い。クエリ操作は条件で複数件を取得するが RU はクエリ次第。単一項目が分かっているなら必ずポイント操作を使う。
- ポイント対サイト VPN(P2S)
- 個々のクライアント端末から Azure VNet へ接続する方式。トンネル種別と認証(証明書・RADIUS・Microsoft Entra ID)を選び、VPN クライアント構成を配布する。
- ポート・プロセス調査(nmap/lsof/fuser)
- nmap は外部からポートをスキャンして実際の見え方を確認、lsof(lsof -i:80)や fuser はポートやファイルを掴んでいるプロセスを特定する。内側の ss と外側の nmap の差分がファイアウォールの効果。
- ポート・接続状態の調査(ss/netstat/netcat)
- ソケットやポートの状態を調べる。ss はソケット一覧(netstat の後継。ss -tlnp で TCP の LISTEN をプロセス付きで確認)、netcat(nc)は任意ポートへの接続テスト(nc -zv host 443)。ファイアウォールで落ちているのかサービスが居ないのかを切り分ける。
- ポートスキャン
- 対象ホストの各ポートへパケットを送り、応答の有無やその内容から開いている(稼働中サービスがある)ポートを調べる偵察行為。攻撃者は攻撃対象の探索・脆弱性のある稼働サービスの特定に用い、TCP SYNスキャンなど完全な接続を確立しない手法は検知を回避しやすい。IDS/IPSやログ監視で単位時間あたりの接続試行数の異常として検知する。
- ポートセキュリティ
- スイッチのポートごとに、学習・許可するMACアドレス数の上限や特定のMACアドレスを設定し、上限超過や未許可MACの検出時にポートを遮断またはフレームを破棄する機能。大量の偽装送信元MACでテーブルを溢れさせるMACアドレステーブルオーバーフロー(MACフラッディング)攻撃を防ぐ。
- ポートリダイレクト
- あるポート宛の通信を別のポートやホストへ転送する仕組み。iptables の NAT テーブル(DNAT)などで実現し、外部公開ポートを内部の実サービスへ振り向ける用途で使う。
- ポート番号
- 同じ IP アドレス上で動く複数のサービスを識別する 16 ビットの番号(例:HTTP は 80、HTTPS は 443、SSH は 22)。TCP・UDP のヘッダーに含まれ、ファイアウォールやセキュリティグループのルールは送信元/宛先ポートで通信を許可・拒否する。
- ポート変換(Docker)
- コンテナ内のポートをホスト側のポートへ対応付ける仕組み。docker run -p ホスト側:コンテナ側 のように指定し、外部からホストの特定ポートへアクセスするとコンテナ内のサービスに転送される。
- ポーリング vs Webhook(プッシュ/プル)
- 連携の2方式。ポーリング(プル)=こちらから定期的に問い合わせる(実装簡単だが遅延・無駄が出る)。Webhook(プッシュ)=相手がイベント時に呼んでくる(即時・効率的だが受け口の可用性が要る)。AWS では EventBridge/SNS がプッシュ、SQS 受信がプル。
- ホストプール(プール型/個人型)
- Azure Virtual Desktop で同一構成のセッションホスト(VM)をまとめる単位。プール型は複数ユーザーが共有しマルチセッションでコスト効率が高い。個人型は 1 ユーザーに 1 ホストを固定割当し状態を保持する。
- ホストプールの負荷分散(breadth-first / depth-first)
- プール型ホストプールで新規セッションをどう割り振るかの方式。幅優先(breadth-first)は全ホストに分散して体感を均一にし、深さ優先(depth-first)は 1 ホストを上限まで埋めてから次へ回し VM 数とコストを抑える。
- ホスト鍵
- SSH サーバーが自分自身を証明するために持つ鍵ペア(/etc/ssh/ssh_host_*_key)。クライアントは接続時にこの鍵の指紋を known_hosts と照合し、なりすましや中間者攻撃を検知する。
- ボットネット
- マルウェア(ボット)に感染した多数の機器がC&Cサーバの指令下で一斉に制御されるネットワーク。DDoS攻撃やスパム送信、情報窃取の踏み台として悪用される。感染機器はコネクトバック通信で指令を待ち受ける。
- ポリグロットパーシステンス
- データの特性ごとに最適なデータストアを使い分ける考え方。強い整合性・結合が要る業務データはRDB、単純な高速参照はKVS、階層的な文書は文書データベース、関係の探索はグラフデータベースというように用途で選ぶ。単一DBに無理に押し込めない代わりに、複数ストア間の整合性維持や運用コストの増加をアーキテクトが引き受ける判断になる。
- ポリシー(メンバーができること)
- 組織/Enterprise の設定で、メンバーができること(リポジトリ作成・可視性・フォーク・Actions 利用・GHAS 有効化など)を統制する。Enterprise の方針は下位の組織/リポジトリへ波及する。コード変更のガードレールであるルールセットとは別レイヤー。
- ポリシーテンプレート(カスタムコネクタ)
- カスタムコネクタの実行時の動作(ヘッダー/URL/パラメーターの設定・変換)をコードなしで変更する仕組み。
- ポリシーベース vs ルートベース VPN
- ポリシーベース=トラフィックセレクターで対象を固定(静的・S2S 単一接続向け)。ルートベース=ルーティングで柔軟(P2S・複数接続・共存に必要)。多くは後者を選ぶ。
- ホワイトボックステスト
- プログラムの内部構造(ロジック)に着目し、すべての分岐やパスが意図通り実行されるかを検証するテスト手法。命令網羅・分岐網羅などの網羅基準を用いる。
- マーケティングミックス(4P)
- Product(製品)・Price(価格)・Place(流通)・Promotion(プロモーション)の4つの視点でマーケティング施策を組み立てるフレームワーク。売り手側の視点で整理する。
- マージ(Power Query)
- Power Query で、共通のキー列をもとに別テーブルの列を取り込む列方向の結合操作(SQL の JOIN 相当)。結合の種類(内部・左外部・右外部・完全外部・アンチ結合)を選べ、結果は入れ子になった新しい列として展開して使う。
- マージコンフリクト
- 同じ箇所を別々に変更したときに起きる競合。手動で解決してから統合を完了する。
- マイクロサービス
- アプリケーションを小さく独立したサービス群に分割するアーキテクチャスタイル。サービスごとに個別デプロイ・個別スケール・障害分離ができる一方、サービス間通信や運用の複雑さが増す。コンテナやサーバーレス基盤、API ゲートウェイと組み合わせて構築されることが多い。
- マイコン(MCU)
- CPUコア・メモリ(フラッシュ/SRAM)・周辺I/O(タイマ/UART/AD変換等)を1チップに集積した組込み向け処理デバイス。汎用CPU+外部メモリ構成に比べ低コスト・低消費電力・省スペースで、家電やIoT機器の制御に広く使われる。用途(処理性能/消費電力/ピン数/価格)に応じたMCU選定が組込み設計の出発点になる。
- マネージド ID
- シークレットの管理なしにアプリが Azure リソースへ安全にアクセスできる ID。Azure が自動管理するサービスプリンシパル。
- マネージドインスタンスグループ(MIG)とインスタンステンプレート
- インスタンステンプレート(VM の設計図)に基づき同一構成の VM を作成し、オートスケールや自己修復を行う Compute Engine のグループ。
- マネージドオンラインエンドポイント
- リアルタイム低遅延の推論を提供し、Azure がインフラとオートスケールを管理するエンドポイント。Kubernetes オンラインは既存 AKS を使う。
- マネージドサービス(管理の境界)
- AWS が運用の一部を肩代わりするサービス区分。フルマネージド(パッチ/スケール/可用性まで AWS)ほど運用負荷が下がる一方、制御は減る。アンマネージド(EC2 等)は柔軟だが自己管理。責任共有モデルの「どこまでが自分の責任か」を決める軸。
- マネージドディスク
- VM のディスクを Azure が管理するブロックストレージ。種別は Ultra/Premium SSD v2/Premium SSD/Standard SSD/Standard HDD。スナップショットやディスク暗号化(SSE/ADE)に対応する。
- マネージドプレフィックスリスト
- 複数の CIDR を 1 つの名前付きリストにまとめ、セキュリティグループやルートテーブルで参照する仕組み。エントリ変更が参照先すべてに反映され、規則の保守を簡素化する。
- マネージド環境
- 統制機能を強化した環境の運用モード。共有制限・使用状況分析・データポリシーなど、ガバナンスを一括で適用できる。
- マネジメント予備
- 未知のリスク(予見できないスコープ内の作業)に備えて確保する予備費で、コストベースラインには含まれずプロジェクト予算の一部として管理される。使用にはスポンサーなど上位の承認が必要な点がコンティンジェンシ予備と異なり、混同するとEVM算出のBACの範囲を誤る。
- マルウェア
- ウイルス・ワーム・トロイの木馬・ランサムウェアなど、利用者に害を及ぼすことを目的として作られた悪意あるソフトウェアの総称。感染経路はメール添付・不正サイトの閲覧・USBメモリなど多岐にわたる。
- マルウェアの種類(ウイルス・ワーム・トロイの木馬・スパイウェア)
- 代表的なマルウェアの分類。ウイルスは他のプログラムやファイルに寄生し、宿主が実行されることで感染・増殖する。ワームは宿主を必要とせず自己複製してネットワーク経由で自律的に感染を広げる。トロイの木馬は無害な正規プログラムを装って侵入し、自己増殖はせず内部で不正動作を行う。スパイウェアは利用者に気付かれずに情報を収集し外部へ送信する。
- マルウェア解析(リバースエンジニアリング)
- 検体を安全な環境で実際に動かして挙動を観察する動的解析と、逆アセンブル・逆コンパイルによりコードそのものを解析する静的解析(リバースエンジニアリング)を組み合わせ、マルウェアの機能・通信先・侵害範囲を明らかにする作業。SOCアナリストは解析結果からIoCを抽出し検知ルールへ反映する。
- マルウェア除去
- 感染が疑われる端末に対し、まず被害拡大を防ぐため端末をネットワークから隔離し、ウイルス対策ソフトでフルスキャンを実行して検出されたマルウェアを隔離・削除する一連の対応。スキャンログで検出内容と対処結果を確認し、除去後は再感染の有無を確認する。深刻な場合はOSの再インストールや信頼できるバックアップからの復旧など、より強い修復手段を検討する。
- マルチアカウントのネットワーク設計
- 多数アカウント/VPC を Transit Gateway や Cloud WAN のハブで集約し、共有サービス VPC・集中型 egress・集中型検査(インスペクション VPC)でセキュリティとコストを最適化する。
- マルチアカウント戦略
- ワークロード・環境・チームをアカウントで分離し、課金・セキュリティ・ブラストラディウスを区切る設計。Organizations+OU+SCP で統制し、Control Tower で標準化されたアカウントを払い出す(アカウントベンディング)。Landing Zone がその基盤。
- マルチキャスト
- 特定のグループに参加したホストにだけ一斉配信する通信方式。ブロードキャスト同様クラウドの仮想ネットワークでは標準サポートされないことが多く、必要な場合はトランジットゲートウェイのマルチキャスト機能のような専用サービスを使うか、設計をユニキャスト前提に置き換える。
- マルチクラウド
- 複数のパブリッククラウド事業者を併用する形態。ロックイン回避や適材適所が目的。
- マルチメディア
- 文字・静止画・動画・音声など複数の種類の情報(メディア)を組み合わせて統合的に扱うこと、またそのような技術・コンテンツ。Webページや電子教材のように、複数のメディアを組み合わせることで表現力や分かりやすさを高められる。
- マルチリージョンアクセスポイント
- 複数リージョンに分散した S3 バケットへ、単一のグローバルエンドポイントでアクセスできるようにする機能。AWS Global Accelerator の仕組みでリクエストを発信元に最も近いリージョンへ自動ルーティングし、フェイルオーバーやレイテンシ改善に使う。
- マルチリージョン構成(アクティブ-アクティブ/スタンバイ)
- 複数リージョンへ展開し、地域障害や低遅延に備える構成。アクティブ-アクティブ=両リージョンで処理(高可用・高コスト・データ整合が課題)。アクティブ-スタンバイ=片方は待機(フェイルオーバーで昇格)。Route 53・Global Accelerator・グローバルテーブルで実現する。
- マルチリージョン書き込みと競合解決
- 全リージョンで書き込めるようにして低遅延・高可用を得る構成。同一項目が別リージョンで同時更新されると競合が起き、Last Write Wins(LWW・既定)かカスタム競合解決(ストアドプロシージャ)で解決する。strong 一貫性とは併用できない。
- マルチ管理者承認(Intune)
- スクリプトの実行など影響の大きい構成変更に対し、申請者とは別の管理者が承認するまで適用を保留する仕組み。単独の管理者による誤操作や内部不正で重大な変更が本番へ即座に反映されるのを防ぐ、四つ目の目(four-eyes)原則の実装。
- ミューテックス
- 複数タスクが共有資源へ排他的にアクセスするための同期機構。カウント値0/1のバイナリセマフォに似るが、ロックしたタスクのみが解放できる「所有権」の概念を持つ点が異なり、これにより優先度継承プロトコルの適用が可能になる。組込みRTOSでは共有変数やハードウェアリソースの排他制御に用いる。
- ミラーリング(Mirroring)
- 外部データベース(Azure SQL・Snowflake・Cosmos DB など)の変更を、ほぼリアルタイムに OneLake へ複製する機能。CDC を使い、ETL を組まずに分析できる。
- メールログ検索(Email Log Search)
- 特定のメッセージの配信状況(配信済み・拒否・スパム判定・遅延)を追跡するツール。原因究明にはヘッダー分析(経路・SPF/DKIM/DMARC の結果)を併用する。横断調査と一括対処は調査ツール。
- メジャー
- 集計を行う DAX 式。評価時に計算され(遅延評価)モデルに値を保存しない。フィルターコンテキストに応じて結果が変わる。
- メジャーバージョンタグ(@v4)
- 利用者が @v4 のように参照するタグ。提供者は新リリースごとにメジャータグを最新コミットへ移動し、利用者は修正を自動で受け取る。
- メタデータフィルタリング(RAG)
- チャンクに属性(出典・日付・部門・機密区分など)を付与し、検索時にフィルタして関連性とアクセス制御を高める手法。テナント分離や最新版優先、権限に応じた可視範囲の制御を、ベクトル検索と組み合わせて実現する。
- メタバース
- インターネット上に構築された3次元の仮想空間で、利用者がアバター(分身)となって他の人と交流したり、買い物やイベントなどの活動を行える場。VR(仮想現実)やAR(拡張現実)の技術を応用して実現される。
- メダリオンアーキテクチャ
- データを品質段階で層化する設計。ブロンズ(生)→シルバー(クレンジング/結合)→ゴールド(集計/ビジネス向け)と進め、各層を Delta で保存する。
- メッセージキュー
- タスク間またはタスクと割込みハンドラ間でデータを受け渡すための、FIFO(先入れ先出し)方式のバッファ機構。送信側はキューにメッセージを積み、受信側は届くまで待機(ブロック)できるため、直接の関数呼出しより疎結合にタスクを連携させられ、生産者-消費者型の処理に適する。
- メッセージとイベントの違い
- メッセージ=送信側が処理を期待する「指示(コマンド)」(Service Bus/Queue)。イベント=起きた事実の「通知」(Event Grid/Event Hubs)。選定の軸になる。
- メッセージング ポリシー(messaging policies)
- チャットの機能(メッセージの編集/削除・既読・ジフ/ステッカー・優先度・翻訳など)をユーザー単位で許可/禁止する。チャネルの種別とは別。
- メッセージング/イベント(Service Bus・Event Grid・Event Hubs)
- 疎結合連携の選択肢。Service Bus=エンタープライズメッセージング(キュー/トピック・順序/トランザクション/重複排除/デッドレター)。Storage Queue=シンプルで安価な大量キュー。Event Grid=離散イベントのリアクティブな pub/sub(「Blob 作成」等)。Event Hubs=大量ストリーミング/テレメトリ取り込み(高スループット・パーティション)。メッセージ=指示、イベント=通知。
- メッセージングシステム
- アプリケーション間でメッセージ(イベントやタスク)をやり取りする基盤。キューを用いて送信側と受信側を疎結合にし、非同期データ処理を可能にする。
- メッセージ順序保証
- 送信順とおりに処理されることの保証。標準 SQS/SNS は順序を保証しない(高スループット)。FIFO はメッセージグループ単位で順序を保証する。順序が要る場合はグループ ID 設計や単一コンシューマーで対処する。
- メトリクス計算(Metric Math)
- 複数のメトリクスを数式で組み合わせて新しい時系列を作る機能。エラー率(エラー数÷総数)や合計、異常検出バンドなどを算出し、アラームやダッシュボードに使う。
- メトリック
- ルーティングプロトコルが最適経路を選定するために用いる数値指標。ホップ数・帯域幅・遅延・コストなど、プロトコルごとに異なる基準で算出され、値が小さいほど優先される経路として経路表に採用される。同一プロトコル内での経路比較に用い、異なるプロトコル間の比較にはアドミニストレーティブディスタンスが用いられる。
- メモリマップドI/O
- 周辺装置のレジスタをメモリのアドレス空間の一部に割り当て、通常のメモリアクセス命令(読み書き)で周辺機器を制御する方式。専用のI/O命令を持つ独立I/O方式に比べ命令セットが単純化でき、多くの組込みプロセッサで採用される。ただしキャッシュにより書き込みが遅延・省略されないよう、当該領域をキャッシュ禁止にする設計配慮が要る。
- メモリ関連パラメータ(shared_buffers/huge_pages/work_mem/maintenance_work_mem)
- メモリ関連の主要性能パラメータ。shared_buffers は共有バッファ(データキャッシュ)の大きさ、huge_pages はOSの大ページ機能利用有無、work_mem はソートやハッシュ結合など1操作あたりの作業用メモリ量(外部マージ発生を左右)、maintenance_work_mem は VACUUM や CREATE INDEX 等の保守作業に使うメモリ量を制御する。
- メンテナンスウィンドウ
- マネージドデータベースの計画的なメンテナンス(パッチ/マイナーバージョン更新等)を実施する時間帯。可用性要件に合わせ、業務影響の小さい時間帯に設定して計画停止を制御する。
- モジュールの結合度と凝集度(強度)
- モジュール分割の良し悪しを測る2つの尺度。結合度はモジュール間の依存の強さを表し、独立性を高めるため低いほど良い(データ結合が最良、内容結合が最悪)。凝集度(強度)は1つのモジュール内の機能のまとまりの強さを表し、高いほど良い(機能的凝集が最良、暗合的凝集が最悪)。良い設計の指針は「結合度は低く、凝集度は高く」。
- モジュール分割技法(STS分割・TR分割・共通機能分割)
- プログラムを保守しやすい単位に分割する代表的手法群。STS分割はデータフロー図の最大抽象入力点と最大抽象出力点で源泉(Source)・変換(Transform)・吸収(Sink)の三つに分ける手法、TR分割は入力の種別(トランザクション)ごとに処理を振り分ける手法、共通機能分割は複数箇所で共用される機能を独立モジュールとしてくくり出す手法である。システムアーキテクトは処理特性に応じてこれらを使い分け、高凝集・低結合の構造を導く。
- モジュール分割技法と情報隠蔽
- プログラムを独立性の高い単位に分割する設計技法(STS分割・共通機能分割・データ分割など)と、モジュール内部の実装詳細を外部から隠し、公開インタフェースのみで操作させる情報隠蔽の原則。変更の影響範囲を局所化し保守性を高める。
- モダリティマッピング(前処理の振り分け)
- 入力の種類に応じて適切な AWS サービスへ前処理を振り分ける設計。文書/画像=Textract、音声=Transcribe、一般画像理解=Rekognition/マルチモーダル FM、テキスト正規化=Comprehend。抽出・正規化してから生成 AI に渡す。
- モダンデータウェアハウスアーキテクチャ
- 取り込み→保存(データレイク)→準備・変換→モデル化・提供(DWH)→可視化、という分析の流れ。バッチとストリームを組み合わせ、Synapse/Fabric が各段を担う。
- モデルカスタマイズ(ファインチューニング/継続的事前学習/蒸留)
- FM を用途へ適合させる手段。ファインチューニング=ラベル付き例で振る舞いを調整(少量データ・タスク特化)。継続的事前学習=大量の未ラベルドメインデータで知識を注入。蒸留=大モデルの出力で小モデルを訓練し低コスト化。多くはまず RAG/プロンプトで足りるか検討してから選ぶ。
- モデルカタログ
- Azure AI Foundry / Azure ML で多数の基盤モデル(OpenAI・Hugging Face・Meta 等)を探索・比較・デプロイできるカタログ。
- モデルとフローの評価
- 生成 AI の出力品質を、グラウンド性・関連性・流暢さ・類似度などの指標や手動評価で測り、フローやモデル選定を改善する。
- モデルのデプロイオプション(Foundry)
- Foundry のモデルを使う方法。サーバーレス API(従量・即利用)と、マネージドコンピューティング(専用エンドポイントにデプロイ)を要件で選ぶ。モデルカタログから選択する。
- モデルのリレーションシップ
- テーブル間の結び付き。ファクト↔ディメンションは原則 1 対多・単一方向。双方向クロスフィルターは必要時のみ(曖昧さや性能低下に注意)。
- モデルの行レベルセキュリティ(ロール)
- セマンティックモデルにロールを定義し、DAX 述語で各ユーザーが見られる行を制限する。動的 RLS は USERPRINCIPALNAME 等で当人の行に絞る。
- モデルの単純化技法(量子化/蒸留/プルーニング)
- 本番の推論レイテンシ・モデルサイズ・コストを下げる手法。量子化(低ビット化)、蒸留(小さいモデルへ知識転移)、プルーニング(不要な重みの除去)。精度とのトレードオフを取る。
- モデルの透明性(AI Service/Model Cards)
- モデルの用途・性能・制限・学習データの考慮事項を文書化する AWS AI Service Cards / SageMaker Model Cards。説明責任とガバナンスを支える。
- モデルベンチマーク比較
- 精度・コヒーレンス・コスト・スループットなどの指標で言語モデルを比較し、用途に合う候補を選ぶための評価。
- モデルレジストリ
- 学習済みモデルをバージョン管理し、ステージや系統(リネージ)とともに登録・参照する場所。デプロイ対象の選択に使う。
- モデルレジストリ(生成 AI の版管理)
- モデルやプロンプト構成、カスタマイズ済み FM をバージョン管理し、承認・ステージング・ロールバックを可能にする台帳。本番に出すモデルの来歴と評価結果を結びつけ、問題時に旧版へ即時復帰できるようにする。
- モデル階層化/モデルカスケード
- 問い合わせの難易度に応じて、簡単なものは小型/安価なモデル、難しいものだけ大型モデルへ振り分けることで、品質を保ちつつコストを最適化する手法。
- モデル監視とドリフト検出
- 本番稼働中のモデルを学習時のベースラインと比較し続け、データドリフト(入力データの分布変化)やモデルドリフト(予測精度の劣化)を検出する仕組み。入出力データをキャプチャして保存し、ドリフト検知をトリガーに再学習パイプラインへつなげる運用が一般的。
- モデル駆動プログラマビリティ
- 機器ごとに異なるCLIコマンドを個別に叩くのではなく、YANGのような共通のデータモデルを介して機器の構成・状態を統一的に操作する考え方。同じモデルであれば異機種・複数ベンダーの機器を同じコード・同じ処理で扱えるようになり、自動化のスケールを支える。
- モデル駆動型アプリ
- Dataverse のデータモデル(テーブル)を土台に、フォームやビューなどのレイアウトが自動生成される Power Apps のアプリ種別。データ中心の複雑な業務(CRM 的なもの)に向く。
- モデル評価指標(適合率/再現率/F1/AUC/RMSE)
- 分類は混同行列(TP/FP/TN/FN)を基礎に適合率/再現率/F1/AUC・PR-AUC。不均衡では精度(accuracy)が誤解を招くためF1/PR-AUCを使う。見逃しを減らす=再現率、誤検知を減らす=適合率。回帰はRMSE(大誤差を強く罰)/MAE(外れ値に頑健)/決定係数R²。しきい値でprecision/recallを調整。
- モノリス
- アプリケーションの全機能を 1 つの大きなコードベース・デプロイ単位にまとめるアーキテクチャスタイル。開発初期はシンプルだが、規模が大きくなるとデプロイ単位が粗くなり、一部の変更のために全体を再デプロイする必要が生じやすい。
- ユーザー・グループ管理(useradd/usermod)
- アカウントを操作するコマンド。useradd 作成(-m でホーム作成)、usermod 変更(-aG でグループ追加。-a を忘れると所属が置換される)、userdel 削除(-r でホームごと)。グループは groupadd/groupmod/groupdel。新規ホームの雛形は /etc/skel/、既定値は /etc/default/useradd。
- ユーザーデータ
- EC2 インスタンスの初回起動時に実行されるブートストラップスクリプト。パッケージ導入や設定を自動化する。既定では起動時に一度だけ実行される。
- ユーザーのライフサイクルと侵害対応
- ユーザーアカウントの作成・停止・削除と、侵害時の対応。停止 / パスワード再設定 / セッション失効で素早く封じ込め、一括アクションで多数を処理、アカウント復旧で誤操作に備える。
- ユーザー中心の評価
- 自動指標だけでなく、実利用者のフィードバック(👍/👎・自由記述・暗黙シグナル)を収集して継続的に品質を評価する運用。golden dataset の自動評価と組み合わせ、現実の満足度とタスク達成度でモデル/プロンプトを改善する。
- ユーザー定義ルート(UDR)
- システムルートを上書きする手動の経路。宛先プレフィックス→次のホップ(仮想アプライアンス/ゲートウェイ/インターネット/なし)を定義し、ルートテーブルをサブネットに関連付ける。
- ユーザー定義関数(Warehouse)
- Fabric Warehouse で再利用可能なロジックを T-SQL でカプセル化する関数。インライン テーブル値関数(インライン TVF)に加え、2025 年からスカラー UDF(1つの値を返す関数)もサポートされた(プレビュー、GA ではない)。スカラー UDF を SELECT 文で使うにはインライン化可能である必要があり、WHILE ループや非決定的関数の呼び出しなどを含むと非対応。共通の計算式を一箇所で保守でき、複数ステートメント TVF 等はオンプレ SQL Server/Synapse との機能差に注意。
- ユーザへの通知
- ログイン前後や稼働中のユーザーへメッセージを伝える仕組み。/etc/issue・/etc/issue.net はログインプロンプト前、/etc/motd はログイン直後に表示され、wall はログイン中の全ユーザーへ即時にメッセージを送る。shutdown はシステム停止前に警告を通知する。
- ユースケース図
- UMLの図の一つで、システムが外部に提供する機能(ユースケース)と、それを利用する人や外部システム(アクター)との関係を表す。アクターを人型、ユースケースを楕円で描き、両者を線で結んでシステム境界を明示し、include(包含)やextend(拡張)で関係を補足する。システムアーキテクトが要求分析の初期に利用者視点で機能範囲を合意し、スコープを可視化する目的で用いる。
- ユニキャスト
- 1 台の送信元から 1 台の宛先へ届ける、最も一般的な 1 対 1 の通信方式。通常のクライアント・サーバー通信やほとんどの API 呼び出しはこの方式を前提に設計される。
- ユニットテストとシークレット管理
- ユニットテストは関数やクラスといった最小単位の処理を個別に検証するテストで、Pythonではunittestやpytestが使われ、CI/CDパイプラインに組み込んで変更ごとに自動実行する。シークレット管理はAPIキーやパスワードといった秘密情報をコードに平文で書き込まず、環境変数やvault(専用の秘密管理サービス)に外出しして扱う実践で、誤ってリポジトリへコミットしてしまう事故を防ぐ。
- ユニバーサルデザイン
- 年齢・障がいの有無・言語・文化などの違いにかかわらず、できるだけ多くの人が利用しやすいように製品や環境をデザインする考え方。特定の利用者だけに配慮するバリアフリーとは対象範囲が異なる。
- ライセンス(シート)
- ユーザー単位で消費する利用枠。ライセンス使用状況を監視して未使用シートを回収する。SCIM/EMU を使うと退職者のシートが自動で空く。
- ライセンスの割り当て(直接/グループベース)
- Microsoft 365 や Copilot の機能はライセンスの種類で決まり、ユーザーへ直接、またはグループベースのライセンスでまとめて割り当てる。Copilot は既存の M365 ライセンスに加えて別途ライセンスが必要。
- ライセンス管理(割り当て・課金・最適化)
- 購入したライセンスをユーザーに割り当て、ユーザー単位の月次/年次で課金し、利用状況を見直して未使用分を回収(最適化)する一連の管理。アドオンで機能を追加できる。
- ライトスルー/ライトバック
- キャッシュへの書込み方式。ライトスルーはキャッシュと主記憶の両方に同時に書き込むため一貫性は保たれるがバス負荷が高く、ライトバックはキャッシュにのみ書き込み後で主記憶へ反映するため高速だが、反映前に電源断が起きるとデータを失うリスクがある。組込みではリアルタイム性とデータ保全のトレードオフで選定する。
- ライフサイクルルール
- Cloud Storage で「作成から N 日後に削除」「N 日後に安いクラスへ移行」を自動化し、コストを最適化するルール。BigQuery では有効期限が同様の役割。
- ライブラリとAPI
- ライブラリは、よく使う機能をまとめて再利用できるようにした部品(関数やクラスの集合)で、自分で一から書かずに呼び出して利用する。API(アプリケーションプログラミングインタフェース)は、そうしたライブラリや外部サービスの機能を、内部実装を知らなくても呼び出せるように定めた取り決め(呼び出し方の仕様)を指す。
- ライブレスポンス
- Microsoft Defender for Endpoint でデバイスへ遠隔シェル接続し、ファイル取得・プロセス停止・スクリプト実行などをその場で行う対話的なインシデント対応機能。RBAC でライブレスポンス権限を分離でき、操作ログはすべて記録され事後監査できる。
- ラベル(GitHub)
- Issue や Pull Request に貼り付けて種別・優先度・状態などを分類するタグ機能。色とその説明を自由に定義でき、検索修飾子 label: での絞り込みや Actions のトリガー条件にも使う。組織/リポジトリ単位で既定ラベル(bug・enhancement 等)が用意される。
- ラベル(コントロール)
- テキストや数値を表示するための基本コントロール。データの値や説明文の表示に使う(入力はできない)。
- ランサムウェア
- 感染したPCやサーバー内のファイルを暗号化して使用不能にし、復号と引き換えに金銭を要求するマルウェア。近年は復号鍵を渡さないだけでなく、窃取したデータの公開を脅す「二重恐喝」の手口が主流になっている。バックアップの取得・分離保管(オフライン化)が有効な対策。
- ランナー(runner)
- Actions のジョブを実行する環境。GitHub ホステッドと自社のセルフホステッドがある。
- ランナーグループ
- セルフホストランナーをまとめ、どの組織/リポジトリが使えるかを制御する単位。機密性の高いランナーを特定リポジトリだけに限定できる。
- リアルタイムOS(RTOS)
- タスクの実行順序や応答時間を決定的(予測可能)に制御し、定められたデッドラインを守ることを重視して設計されたOS。汎用OSがスループットや公平性を重視するのに対し、RTOSは優先度ベースのスケジューリングと短く一定の割込み応答時間を提供し、制御系や通信機器のタイミング要件を満たす。
- リージョナリゼーション(リソースロケーション制約)
- データの保存と処理を特定の国/地域に限定するデータ所在地の要件を、組織ポリシーのリソースロケーション制約で強制する仕組み。データ主権のコンプライアンスに使う。
- リージョン(AWS)
- 地理的に独立した領域で、複数のアベイラビリティーゾーン(通常3つ以上)で構成される。遅延・コンプラ・コスト・サービス提供状況で選ぶ。
- リージョン(Azure)
- 1つ以上のデータセンターをまとめた地理的なまとまり。遅延・データ主権・機能提供・コストで選ぶ。
- リージョンペア
- 同一地理内の離れた2リージョンの組。広域災害への冗長性・順次更新・GRS の複製先に使う。なお2024年以降の新リージョンはペアを持たないものがあり、その場合は可用性ゾーン(ゾーン冗長)で代替する。
- リージョン内の回復性(容量・スロットリング対策)
- 生成 AI 呼び出しの容量逼迫やスロットリングに耐える設計。キャパシティ予約(プロビジョンドスループット)、キュー+指数バックオフでの再試行、複数モデルへのフォールバック、クロスリージョン推論を組み合わせて可用性を保つ。
- リード/ラグ
- リードは後続作業を前倒しで開始できる時間(先行関係に対するマイナスの時間差)、ラグは後続作業の開始を意図的に遅らせる待機時間(プラスの時間差)。スケジュールの現実的な調整に使われ、誤って符号を取り違えると所要期間の算出を誤る点に注意が必要。
- リーンスタートアップとMVP
- リーンスタートアップは、事業アイデアの検証されていない仮説を、最小限の機能で実用に足る製品「MVP(Minimum Viable Product)」を素早く作って顧客に試してもらい、そこから学びを得て(構築-計測-学習のサイクル)方向転換(ピボット)か継続かを判断する新規事業開発の手法。ストラテジストは、需要が不確実な新規事業では詳細な事業計画よりも、MVPによる低コストな仮説検証を優先すべきと判断する際にこの手法を用いる。
- リエントラント(再入可能)
- 複数のタスクや割込みハンドラから同時に、あるいは実行が中断されて再度呼び出されても、共有状態を壊さず正しく動作する性質を持つ関数・コード。内部でグローバル変数や静的変数を書き換えずローカル変数のみで完結させることで実現し、割込みハンドラやマルチタスクから共通に呼ばれる関数には必須の性質。
- リクエスタ支払い(Requester Pays)
- バケットのデータ転送・リクエスト料金を、所有者でなくアクセスする側に負担させる設定。大規模データセットを多数の外部利用者へ共有する際のコスト分担に使う。
- リクエストユニット(RU/s)
- Cosmos DB のスループットと課金の単位。読み取り/書き込み/クエリがそれぞれ RU を消費する。プロビジョニング(手動 RU/s 確保 or オートスケール)かサーバーレス(消費課金)で構成する。RU が不足すると 429(レート制限)が返る。
- リザーブドインスタンスの種別
- スタンダード RI=最大割引だが変更が限定的。コンバーティブル RI=ファミリー/OS 等を変更でき柔軟(割引はやや低い)。リージョン RI=AZ をまたいで柔軟、ゾーン RI=特定 AZ にキャパシティ予約付き。支払いは全額前払い/一部前払い/前払いなし。
- リスク
- 脅威が脆弱性を突いて実際に損害が発生する可能性。一般に「発生確率×影響度」で捉えられ、脆弱性が存在するだけではリスクは生じず、それを悪用しうる脅威と組み合わさって初めて評価対象になる。
- リスクアセスメント
- 情報資産に対する脅威と脆弱性を洗い出し、リスクを特定・分析・評価する一連のプロセス。リスクの大きさ(発生可能性×影響度)を明らかにし、以降のリスク対応の判断材料とする。ISMSのPDCAではPlanフェーズの中核。
- リスクアプローチ(監査における)
- 監査資源が有限であることを前提に、リスクと重要性が高い領域を優先して監査計画・監査手続を組み立てる進め方。すべての業務やシステムを一律の深さで監査するのではなく、固有リスク・統制リスクの評価結果に基づき対象を選別し、リスクの高い領域ほど手続を厚くすることで監査の実効性を高める。これは監査リスク=固有リスク×統制リスク×発見リスクの枠組みに基づき、固有・統制リスクの評価結果に応じて発見リスクを許容水準に抑えるよう監査手続の量・時期・範囲を決めることに対応する。
- リスクベース認証
- ログイン時の状況(アクセス元IPアドレス・端末・時間帯・行動パターンなど)からリスクを動的に評価し、普段と異なる兆候があるときだけ追加の認証(追加のワンタイムパスワード等)を求める認証方式。利便性と安全性を両立する。
- リスクマネジメント
- 組織が直面するリスクを特定・分析・評価し、対応策を選択・実施したうえで継続的に見直すマネジメントプロセス全体。リスク分析はその中でリスクの発生確率と影響度を評価する工程を指し、両者は包含関係にある。
- リスク基準
- 組織がリスクの大きさを評価し、対応が必要かどうかや優先順位を判断するために、あらかじめ定めておく基準。許容できるリスクの水準(リスク受容基準)を含み、リスク評価の工程で分析結果をこの基準と照らし合わせて対応の要否を決める。基準は組織の方針・法令・事業環境に基づいて設定される。
- リスク対応(低減・回避・移転・受容)
- リスクアセスメントの結果に基づき取る4つの対応方針。低減=管理策の導入で発生可能性や影響度を下げる、回避=リスクの原因となる活動自体をやめる、移転=保険や委託で第三者にリスクを移す、受容=許容範囲内として対策せず受け入れる。コストと効果のバランスで選択する。
- リスク分析
- リスクマネジメントの一工程で、洗い出したリスクについて発生確率と影響度を評価し、対応の優先順位付けの基礎とする活動。定性的な評価(影響の大小を段階分け)と定量的な評価(金額換算)の両アプローチがある。
- リスト(;/&&/||)
- コマンドを連結する演算子。A ; B は成否に関係なく順に実行、A && B は A が成功したときだけ B、A || B は A が失敗したときだけ B を実行する。
- リソース アカウント(resource account)
- 自動応答(auto attendant)や着信キュー(call queue)に電話番号を割り当てるために必要なアカウント。一般ユーザーの番号とは別。
- リソースグループ
- 関連するリソースをまとめるコンテナ。権限やライフサイクルを一括管理。リソースは必ず1つのRGに属す。
- リソースベースポリシー
- S3 バケットポリシーや SQS キューポリシーのようにリソース側にアタッチし、「誰がこのリソースにアクセスできるか」を定義するポリシー。Principal 要素を持てるため、対象リソースを持たない別アカウントのプリンシパルにもアクセスを許可でき、クロスアカウントアクセスの実現に有効。
- リソースレコード
- ゾーンファイルに記述する DNS の設定単位。SOA(ゾーンの権威情報)、NS(ネームサーバー)、A/AAAA(IPv4/IPv6 アドレス)、MX(メールサーバー)、CNAME(別名)、PTR(逆引き)などの種類がある。
- リソースロック
- 削除や変更を防ぐ安全網(CanNotDelete / ReadOnly)。権限があっても誤操作を止める。
- リソース階層
- 組織→フォルダ→プロジェクト→リソースという Google Cloud の階層。プロジェクトが課金/権限の基本単位で、ポリシーは階層に沿って継承される。
- リダイレクト(>/>>/2>&1)
- ストリームの入出力先を付け替える。> は標準出力をファイルへ上書き、>> は追記、< はファイルを入力に。両方をまとめて保存するのは > file 2>&1(順序が重要)。捨て先は /dev/null。
- リトライ設計
- 一時的な障害に対し、指数バックオフとジッターを使って再試行する設計。単純な即時リトライは、大量クライアントの再試行が同時に集中するリトライストームを招き障害を悪化させるため、ランダムな遅延(ジッター)で分散させる。冪等な操作でのみ安全に使える。
- リトロハント(retrohunt)
- 新しい検出ロジックや新たに判明した IOC を、過去に取り込んだイベントデータに遡って適用し、見逃していた侵害を発見する手法。Google SecOps ルールエンジンや BigQuery/Cloud Logging で行う。
- リバースエンジニアリング
- 既存のプログラムや成果物を解析し、その構造から設計情報や仕様を復元する手法。設計文書が失われた既存システムの理解や再構築の起点として用いる。これに対し仕様から実装へ順方向に展開するのがフォワードエンジニアリングであり、リバースで得た仕様を改善してフォワードで作り直す一連の再構築がリエンジニアリングである。システムアーキテクトはレガシー刷新でこれらを組み合わせて既存資産を活用する。
- リバースプロキシ
- サーバー側に立ち、クライアントからのリクエストを背後の実サーバー(複数の場合も)へ振り分けて中継するプロキシ。負荷分散やSSL終端、キャッシュに使われる。フォワードプロキシ(クライアント側で使う)とは逆方向。
- リバースレプリケーション
- 移行のカットオーバー後に新環境から旧環境へ書き戻す仕組み。問題発生時に旧環境へ安全に切り戻すためのロールバック保険になる。
- リバース接続トランスポート
- セッションホストに受信ポートを開けず、送信 443 のみでクライアントと接続する Azure Virtual Desktop の既定の接続方式。受信 RDP(3389)を公開する必要がないため攻撃面を減らせる。
- リファクタリング
- プログラムの外部から見た振る舞いを変えずに、内部構造を整理して可読性・保守性を高める作業。重複コードの除去やメソッドの抽出、命名の改善などを、動作を保証する自動テストの支えのもとで少しずつ安全に進める。システムアーキテクトは技術的負債の蓄積を抑え、将来の変更容易性を保つための継続的な設計改善手段として位置づける。
- リファレンスリストとリスク値
- リファレンスリストは既知の悪性値や監視対象、リスク値などを保持する一覧で、検出ルールから参照する。検出ルールはこれを使ってリスクプロファイルに合う脅威を重み付け・優先する。
- リポジトリ
- プロジェクトのファイルと全履歴・メタデータを保持する入れ物。実体は隠しフォルダ .git。
- リポジトリロール
- リポジトリへのアクセスレベル。Read / Triage / Write / Maintain / Admin の段階があり、加えてカスタムリポジトリロールで権限を細かく定義できる。権限は個人ではなくチーム単位で割り当てるのが原則。
- リモート GUI(DISPLAY/xauth/X11 転送)
- リモートの GUI アプリを手元の画面に表示する仕組み。DISPLAY 環境変数が表示先の X サーバーを指し、xauth が接続の認可を管理する。実務では ssh -X(X11 転送)で SSH トンネル越しに表示するのが定番。
- リモート(origin)
- リポジトリの保管先への名前付き参照。clone 時の複製元は既定で origin になる。
- リモート操作(retire / wipe / device query)
- retire は組織データと管理だけを削除し個人データを残す(BYOD 退職時など)。wipe はデバイスを完全に初期化する(紛失・再配布)。device query は KQL でデバイスの状態をその場で照会する。rotate BitLocker recovery keys で回復キーを更新できる。
- リランカー(reranker)
- 検索(取得)後の候補を適合度順に並べ替え、上位結果の質を高める後段の仕組み。ハイブリッド検索の後に適用し、検索そのもの(埋め込み/ベクトル検索)は置き換えない。
- リリース及び展開管理
- 承認された変更を本番環境へ提供するために、リリース単位でビルド・テストを行い、計画に沿って展開する活動。展開方式には一斉展開、段階展開、パイロット(先行)展開があり、リスクと影響範囲に応じて選ぶ。ビルド・テストと本番展開を分離し、リリースパッケージの品質を確認してから展開することで、失敗の影響を限定する。ITサービスマネージャはリリース単位と展開方式を設計し、切り戻しやサービス停止時間を織り込んで移行を統制する。
- リレーショナルオブジェクト(ビュー/ストアドプロシージャ)
- テーブルに加え、ビュー(保存したクエリ)、ストアドプロシージャ(手続き)、関数などのデータベースオブジェクトでデータアクセスを構造化する。
- リレーショナルデータベース
- データをテーブルに格納し、キーでテーブル間を関連づけるDB。SQL で操作。
- リレーショナルデータモデル
- データを行(タプル)と列(属性)から成る2次元の表(リレーション)の集合として表現するデータモデル。表同士はキーを介して関連付けられ、集合演算に基づく問い合わせ(SQL)で操作する。
- リレーションシップ
- データモデリングにおいて、エンティティ間の関連(対応関係)を表す概念。1対1・1対多・多対多といった多重度で表現され、E-R図ではひし形や線で示される。多対多の関連は実装時に連関エンティティ(中間テーブル)へ分解される。
- リレーションシップ(Dataverse)
- テーブル間の関連付け。1 対多(親 1 件に子が複数)と多対多(双方が複数)があり、関連データの参照や絞り込みに使う。
- リンクアグリゲーション(LACP)
- 複数の物理リンクを論理的に1本の高帯域リンクとして束ね、全リンクを同時にデータ転送に使う技術(IEEE802.3ad/制御にLACP)。帯域を合算できると同時に、一部リンク障害時も残りで通信を継続でき冗長性も得られる。片方を待機させるSTPの冗長化とは異なる。
- リンクローカルアドレス
- IPv6において同一リンク内でのみ有効なアドレスで、fe80::/10の範囲を用いる。ルータを越えて転送されず、インタフェースには自動的に必ず付与される点でグローバルユニキャストアドレスと異なる。近隣探索プロトコル(NDP)などリンク内制御通信に用いられる。
- ルータID(OSPF)
- OSPFプロセスがネットワーク内でルータを一意に識別するために使う32ビットの値。明示的に手動設定しない場合、ループバックインタフェースの最大IPアドレス、なければ物理インタフェースの最大IPアドレスが自動選出される。ルータID重複は隣接関係の形成を妨げる典型的な障害原因となる。
- ルータとハブ(ネットワーク機器)
- ハブは複数の機器をLANにつなぐ集線装置。宛先に関係なく全ポートへ流すリピータハブと、宛先ポートにだけ送るスイッチングハブがある。ルータは異なるネットワーク同士(例:家庭のLANとインターネット)を橋渡しし、ルーティングテーブルをもとにIPアドレスの宛先へ最適な経路で転送する機器で、社内の私的アドレスと外部のグローバルアドレスを変換するNAT機能ももつ。
- ルーティング
- ネットワーク上でパケットを送信元から宛先まで届けるための経路を決定する処理。ルータが保持する経路表(ルーティングテーブル)を基に、静的に設定する方式と、RIPやOSPFなどのルーティングプロトコルで動的に交換・更新する方式がある。
- ルーティング(システムルート・サービスチェイニング・強制トンネリング)
- Azure の経路制御。システムルート=VNet 内・ピアリング・ゲートウェイ・既定インターネットへの経路を Azure が自動付与。UDR(ユーザー定義ルート)でこれを上書きし、宛先プレフィックス→次のホップ(仮想アプライアンス/ゲートウェイ/インターネット/なし)を定義する。サービスチェイニング=UDR の次ホップを NVA(ファイアウォール)にして必ず経由させる(NVA 側で IP 転送が必須、冗長化は内部 Load Balancer を前段に)。強制トンネリング=外向きインターネットを UDR でオンプレ経由に強制。ゲートウェイトランジット=スポークがハブの VPN/ExpressRoute ゲートウェイを共有。経路選択は最長プレフィックス一致→UDR>BGP>システム。
- ルーティングテーブル(経路表)
- ルータが保持する、宛先ネットワークとその到達に用いる次ホップ・出力インタフェース・メトリックなどを対応付けた表。静的経路・動的プロトコルで学習した経路・直接接続経路が統合され、パケット転送時にロンゲストマッチにより最適エントリが選択される。
- ルーティングプロトコルの分類(ディスタンスベクタ型・リンクステート型・パスベクタ型)
- ルーティングプロトコルの動作方式による分類。ディスタンスベクタ型は隣接ルータから距離・方向の情報のみを交換し経路表を段階的に更新する(例:RIP)。リンクステート型は各ルータがネットワーク全体のトポロジ情報を保持し最短経路木を計算する(例:OSPF)。パスベクタ型は経由するAS番号の並びを経路属性として交換し、ループ回避とポリシー制御に用いる(例:BGP)。
- ルートキット
- 侵入後に自身や他の不正プログラムの存在を隠蔽し、管理者権限での活動を継続させるためのツール群。OSの深部(カーネル等)に潜り込み、プロセスやファイル、通信を偽装して検知を困難にする。
- ルートテーブル
- サブネットのトラフィックの行き先を決める規則表。宛先 CIDR ごとにターゲット(IGW・NAT GW・ピアリング・エンドポイント等)を指定する。最長一致が優先。ローカルルート(VPC 内)は削除できない。
- ルートブリッジとその選出
- ルートブリッジはSTPが構築するツリー型トポロジの根となる基準点で、全スイッチが自身からルートブリッジへの最短経路を計算する基準になる。選出はBPDUに含まれるブリッジID(ブリッジプライオリティ+MACアドレス)が最小のスイッチが自動的にルートブリッジとなり、プライオリティが同値の場合はMACアドレスが小さい方が選ばれる。管理者はプライオリティ値を明示的に下げることで意図したスイッチをルートブリッジに固定できる。
- ルートユーザー
- アカウント作成時の全権限ユーザー。MFAで保護し日常作業では使わず、IAMユーザー/ロールを使う。
- ルートユーザーの保護
- アカウント作成時の最上位 ID=ルートユーザーはほぼ全権を持つため、日常利用せず保護する。MFA を有効化、アクセスキーを作らない/削除、強固なパスワード、請求/解約など一部の操作のみに限定。Organizations の集中管理で利用を監視する。
- ルート優先度
- 同一宛先に複数のルートがあるときに、どれを採用するかを決める値。値が小さいほど優先される。ネットワークタグと組み合わせて適用先を絞れる。
- ループと分岐
- 繰り返し処理(Apply to each などのループ)と条件分岐(条件・スイッチ)でフローの流れを制御する仕組み。
- ルールセット(ruleset)
- ブランチ保護・必須レビュー・必須ステータスチェックなどを組織横断で強制するガードレール。ポリシー(メンバーの権限)とは別レイヤーで、コード変更に対する統制を担う。
- ルールベース検知・振る舞い検知・統計的検知
- 検知手法の3類型。ルールベース検知は既知の攻撃パターン(シグネチャ)との一致で検知し既知の脅威に強いが未知の攻撃は見逃しやすい。振る舞い検知は正常な挙動から外れる行動を捉え未知の脅威にも対応できるが誤検知が増えやすい。統計的検知は通常のベースラインからの数値的な偏差(急激なトラフィック増加等)を異常として検知する。
- レイクハウス(Fabric Lakehouse)
- ファイルとテーブルを一体で扱える Fabric のアイテム。Spark/ノートブックで処理し、自動生成される SQL 分析エンドポイント(読み取り専用)で T-SQL クエリもできる。
- レイヤードアーキテクチャ(3層アーキテクチャ)
- ソフトウェアの責務を層に分割し、上位層は原則として直下の層のみに依存させる構造パターン。関心の分離により保守性・可換性・テスト容易性が高まり、ある層の実装差し替えが他層に波及しにくい。プレゼンテーション・ビジネスロジック・データアクセスの3層構成が代表例で、物理的なクライアントサーバの3層配置とは概念が異なる点に注意する。
- レインボーテーブル攻撃
- ハッシュ値から元のパスワードを高速に逆引きするために、あらかじめ計算した平文とハッシュ値の対応表を用いる攻撃。パスワードごとに異なるソルトを付加してハッシュ化すれば、この事前計算表が無効化される。
- レートアノマリ
- 無線LANが同一チャネルを共有する半二重媒体であることに起因し、低速な端末が同じデータ量の送信により長くチャネルを占有するため、同一チャネルを共有する高速端末の実効スループットまで低速端末に引きずられて低下する現象(rate anomaly)。
- レートモノトニックスケジューリング
- 周期タスクに対し、周期が短いタスクほど高い優先度を静的に割り当てるスケジューリング方式。周期・実行時間が既知の固定優先度スケジューリングの中で最適とされ、タスク数nに対し利用率がn(2^(1/n)-1)以下ならスケジュール可能という十分条件(Liu & Layland)で、デッドラインを守れるかを設計段階で検証できる。
- レート制限
- 単位時間あたりに受け付けるリクエスト数の上限を管理し、過負荷や乱用(DoS・スクレイピング等)から後段のシステムを守る仕組み。API ゲートウェイや Web アプリケーションファイアウォールのレートベースルールとして実装されることが多い。
- レガシーコードの近代化
- 古い構文・非推奨 API・冗長な実装を現代的な書き方へ書き換える支援。意味的等価性をテストで確認してから採用する。
- レガシーなサービス管理(inetd/xinetd/chkconfig)
- systemd 以前のサービス管理。inetd/xinetd は要求が来たときだけサービスを起動するスーパーサーバー(設定 /etc/xinetd.d/)。chkconfig/service は RHEL 系の旧来の自動起動管理・起動停止コマンド。不要サービスの停止は攻撃面を減らす基本。
- レコード管理とデータライフサイクル
- Microsoft Purview のレコード管理で、規制対象の文書を保持ラベルで「レコード」として宣言・不変化し、保持期間後に処分レビューを経て削除する。データライフサイクル管理と連携する。
- レジスタ
- CPU内部にある最も高速で小容量の記憶場所。演算対象のデータや命令、アドレス、実行状態などを一時的に保持する。プログラムカウンタ(次に実行する命令のアドレス)、命令レジスタ(取り出した命令)、アキュムレータ(演算結果)などの種類がある。
- レジストリ(ワークスペース横断共有)
- モデル・コンポーネント・環境・データを複数のワークスペース間で共有する組織レベルのカタログ。開発から本番へ昇格させる際に使う。
- レスポンシブデザイン
- 画面サイズ(PC/タブレット/スマホ)に応じてレイアウトを自動調整する設計。キャンバスアプリではコンテナーや数式で実現する。
- レビュー
- 成果物(設計書やプログラムなど)を関係者が読み合って誤りや問題点を早めに見つける活動。テストで実行する前の上流工程で欠陥を発見できるため、後工程での手戻りを減らせる。
- レビュー技法(ウォークスルーとインスペクション)
- コードや設計書を実行せずに欠陥を発見する静的検証技法。ウォークスルーは作成者主導で参加者に説明しながら進める比較的軽量な手法、インスペクションはモデレータが司会し役割分担・チェックリストに基づき厳格な手順で行う最も形式的な手法。工程の早い段階で欠陥を安価に除去できる。
- レプリケーション
- データベースなどのデータをマスター(主系)からレプリカ(複製先)へ複製する仕組み。読み取り負荷の分散や、マスター障害時のフェイルオーバー先として使われる。
- レポート(Power BI)
- 1 つのデータセットに基づく複数ページの対話的な分析。ビジュアルを配置し、フィルターやドリルダウンで深掘りできる。Power BI Desktop で作成する。
- レポートとデータの可視性(Intune)
- Intune の管理センターで、組織/デバイス/ポリシーレベルの reports・workbooks・dashboards を通じてコンプライアンス状況や展開状況を可視化し、CSV 等へエクスポートしてさらに分析できる機能群。運用レポート(Operational reports)と組織全体のダッシュボードの両方をカバーする。
- ローカルネットワークゲートウェイ
- S2S VPN で「オンプレ側」を表す Azure 上のオブジェクト。オンプレの公開 IP とアドレス空間(または BGP 設定)を登録する。
- ローコード
- コードをほとんど書かず、設定やドラッグ&ドロップ中心でアプリ/自動化を作る開発手法。少量のコード(式など)は併用できる。開発スピードと現場主導の改善が利点。
- ローコード開発
- プログラムのコードをほとんど書かず、画面上の部品を組み合わせたり設定したりする操作を中心にアプリを開発する手法。コードを全く書かないものはノーコードと呼ぶ。専門の開発者でなくても業務アプリを素早く作れる利点がある。
- ロードアベレージ
- 実行可能/実行中のプロセス数の平均で表すシステム負荷の指標。uptime や top で 1分/5分/15分の3つが表示され、CPU コア数と比べて過負荷かを判断する。
- ロードバランサ(L4/L7)
- 複数サーバへ負荷を分散する装置。L4ロードバランサはIPアドレスとポート番号までで振り分ける。L7ロードバランサはHTTPのURLパスやCookie等アプリケーション層の情報を解釈でき、パスベースの振り分けやCookieによるセッション維持(パーシステンス)を実現する。ヘルスチェックで異常サーバを自動的に振り分け対象から除外する。
- ロードバランサの分散方式(ラウンドロビン/最小コネクション)
- ラウンドロビンは実サーバへ順番に均等にリクエストを割り当てる最も単純な分散方式で、各リクエストの処理負荷が均一な場合に有効だが、処理時間のばらつきがあると特定サーバに負荷が偏りうる。最小コネクション方式はその時点で処理中の接続数が最も少ないサーバへ優先的に割り当てる方式で、リクエストごとの処理時間差が大きい環境でも負荷を実態に近い形で平準化できる。
- ロードバランシング(ロードバランサ)
- 複数のサーバーへリクエストを振り分けて負荷を分散させる仕組み、またはそれを行う機器・ソフトウェア。単一サーバーへの集中を避け、可用性とスケーラビリティを高める。DNS ラウンドロビンも簡易な実現方法の一つ。
- ロール グループ(role groups)
- Microsoft Defender や Microsoft Purview など、個々のワークロード管理センターで権限を委任する単位。ユーザーをロール グループへ追加すると、そのグループに割り当てられたロール(例:Security Reader、Compliance Administrator)の権限を得る。全社的な Entra ID ロールとは別に、ワークロードごとに細分化された最小権限を実現する。
- ロールアップ列(Dataverse)
- 関連する子行を集計(合計・件数・最小/最大等)して値を自動算出する Dataverse の列。非同期ジョブで定期的に再計算され、即時反映ではない点に注意。計算列(同一行の式で即時評価)とは評価タイミングと参照範囲が異なる。
- ロールバックとチェックポイント(リカバリ)
- ロールバックは、トランザクションの障害時にその開始前の状態へデータを戻して整合性を保つ回復操作。チェックポイントは、メモリ上の更新を定期的にディスクへ反映して整合の取れた基準点をログに記録するもので、障害時にはこのチェックポイント以降のログだけを用いてロールフォワード(前進復旧)することで復旧時間を短縮できる。システムアーキテクトはチェックポイント間隔とログ運用を、性能と目標復旧時間の両立から設計する。
- ロールフォワード
- 障害発生前のバックアップに、その後のログ(REDOログ)を順に適用して障害直前の状態まで復元する回復方式。バックアップ以降のコミット済み更新を失わずに復旧できる。
- ロールプレイングディメンション
- 同じディメンション(例: 日付)を複数の役割(注文日/出荷日)で使う設計。非アクティブなリレーションシップを USERELATIONSHIP で計算時に切り替える。
- ロールベースのアクセス制御(RBAC)
- 誰に・どの役割を・どのスコープで割り当てて権限を与える認可の仕組み。最小権限が原則、割り当ては下位へ継承。
- ログ(更新前ログ・更新後ログ)
- データベースの更新内容を記録し、障害からの回復に用いる履歴データ。更新前ログ(更新前の値)はロールバックで変更を巻き戻すために、更新後ログ(更新後の値)はロールフォワードで完了済みの更新を再現するために使われる。
- ログイン状況の確認(who/w/last)
- 誰がいつログインしているかを見るコマンド。who は現在のログイン者、w は加えて何をしているか・負荷、last は /var/log/wtmp 由来のログイン履歴を表示する。
- ログイン制御(シャドウパスワード・/etc/nologin)
- シャドウパスワードはハッシュを root のみ可読の /etc/shadow に分離する仕組み。/etc/nologin はこのファイルが存在すると root 以外のログインを拒否する(メンテナンス時の即席ゲート・中身が表示メッセージ)。
- ログの S3 エクスポート
- CloudWatch Logs に溜まったログを S3 バケットへエクスポートし、長期保管やコスト最適化(Glacier への階層化)、または別ツールでの分析に回す機能。エクスポートはバッチジョブで非リアルタイム。継続的なストリーミング転送が必要な場合は Kinesis Data Firehose のサブスクリプションフィルタを使う。
- ログベースメトリクス
- ログの一致条件から時系列メトリクスを生成する仕組み。特定エラーの出現回数などを監視・アラートの対象にできる。
- ログ管理
- システムやネットワーク機器が記録する操作履歴・通信履歴などのログを、適切に取得・保存・監視・分析する運用。不正アクセスや障害の追跡、原因調査、証跡(証拠)の確保に用いる。改ざん防止のための保護や、複数機器の時刻を合わせる時刻同期(NTP)が正確な分析の前提となる。
- ログ管理と監視(証跡)
- システムやアプリケーションの操作・通信・エラー等の記録(ログ)を収集・保管し、証跡として事後の追跡や監査に利用できるようにする管理と、リアルタイムで異常を検知するための監視の総称。ログは改ざん防止のため書き込み専用の別サーバーへ集約したり、保存期間を定めて適切に管理する必要がある。
- ログ出力しきい値パラメータ(log_min_duration_statement/log_autovacuum_min_duration/log_lock_waits/log_checkpoints/log_temp_files)
- ログへ何を記録するかを制御する監視系パラメータ群。log_min_duration_statement は指定時間を超えた遅いクエリを記録、log_autovacuum_min_duration は時間のかかったautovacuum実行を記録、log_lock_waits はロック待ちが deadlock_timeout を超えたら記録、log_checkpoints はチェックポイント発生情報を記録、log_temp_files は一時ファイル使用をログへ記録する。
- ログ先書き(WAL)
- データページへの変更を実際に反映する前に、必ずその変更内容をログへ先に書き込み確定させる原則。クラッシュが発生してもログから変更内容を復元でき、耐久性(ACID の D)を保証する基盤になる。
- ログ配布(Log shipping)
- トランザクションログのバックアップを別サーバーへ定期的にコピー・復元して待機系を維持する、シンプルで枯れた DR 手法。
- ログ保持期間(Log retention)
- CloudWatch Logs のロググループごとに、ログイベントを自動削除するまでの期間(1日〜10年、または無期限)を設定する機能。既定値は無期限保持のため、コスト管理のためには明示的に設定する必要がある点が実務・試験の両方で頻出の注意点。
- ロケール(LANG/LC_ALL)
- 言語・地域・文字コードの組(ja_JP.UTF-8)。優先順位は LC_ALL(全カテゴリ強制)> LC_*(個別)> LANG(既定)。スクリプトでコマンド出力を parse するときは LANG=C(英語・バイト順)に固定して環境差を消すのが定石。確認は locale(-a で一覧)。国際化(i18n)とローカライゼーション(l10n)の設定にあたる。
- ロジカルレプリケーションの競合(conflict)
- サブスクライバ側で変更の適用に失敗する状態(例:サブスクライバ側にのみ存在するUNIQUE制約への違反)。従来は競合が起きると適用ワーカーが停止し手動解消まで滞留した。PostgreSQL 18 以降は競合検出フレームワークが導入され、insert_exists/update_missing 等の競合種別を検出、pg_stat_subscription_stats で集計、last_update_wins など自動解消も選択できる(*_origin_differs 検出には track_commit_timestamp=on が必要)。
- ロジカルレプリケーション操作(PUBLICATION/SUBSCRIPTION)
- ロジカルレプリケーションの操作コマンド。パブリッシャ側で CREATE PUBLICATION がレプリケーション対象のテーブル集合を定義し(FOR TABLE や FOR ALL TABLES)、ALTER PUBLICATION で対象テーブルを追加/削除、DROP PUBLICATION で削除する。サブスクライバ側では CREATE SUBSCRIPTION でパブリケーションを購読し変更を受信し、ALTER SUBSCRIPTION で ENABLE/DISABLE や REFRESH PUBLICATION(対象パブリケーションの変更をサブスクライバに反映)を行い、DROP SUBSCRIPTION で購読を削除する。
- ロジスティック回帰
- 線形結合の出力をシグモイド関数に通して 0〜1 の確率を得ることで、二値分類を行うモデル。名前に「回帰」とあるが実際には分類器であり、線形回帰同様に解釈しやすく分類問題のベースラインとしてよく使われる。
- ロックと同時実行制御
- 複数トランザクションが同じデータへ同時アクセスする際の整合性を保つ仕組み。LOCK 文で明示的にロックを取得でき、行ロック(row lock)は特定行のみ、テーブルロック(table lock)はテーブル全体を対象にする。PostgreSQLの同時実行制御はMVCC(多版型同時実行制御)を中核とし、読み取りと書き込みが互いをブロックしないことでロック競合を減らす。
- ロック粒度
- ロックをかける単位の粗さ・細かさ。行単位(行ロック)は並行性が高いが管理コストが増え、テーブル単位(表ロック)は管理が軽い一方で並行性が下がる。両者の中間としてインテンションロックで階層的に管理する方式もある。
- ロングテール
- 商品を売上順に並べたとき、少数の売れ筋商品(ヘッド)だけでなく、個々には売上が少ない多数の商品(テール)の合計も無視できない収益源になるという考え方。実店舗と異なり在庫・陳列コストの制約が小さいECサイトで顕著に成立しやすい。
- ロンゲストマッチ
- IPルーティングで、宛先アドレスに一致する経路が複数あるとき、プレフィックス長が最も長い(最も限定的な)経路を優先して選択する原則。デフォルトルート(0.0.0.0/0)は他に一致する経路がない場合の最終手段となる。
- ワークアラウンド(暫定回避策)
- 根本原因を除去する恒久対策が完了する前に、サービスを一時的に回復・維持するために用いる暫定的な回避策。インシデントの影響を軽減して業務を継続させる目的で適用し、有効な回避策はKEDBに記録して再利用する。
- ワークスペース(Fabric)
- アイテム(レイクハウス・ノートブック・パイプライン等)をまとめ、共同作業とアクセス管理を行う単位。容量に割り当てて使う。
- ワークスペース(Power BI)
- Power BI サービス上で、レポート・ダッシュボード・データセットをチームで共同管理・配布する場所。アクセス権を割り当てて共有する。
- ワークスペースロール(Fabric)
- ワークスペースの権限階層 Admin > Member > Contributor > Viewer。最小権限の原則で割り当て、データ単位の権限と組み合わせる。
- ワークパッケージ
- WBSの最下位レベルにあり、それ以上分解せずコスト見積りとスケジュール管理を行える作業の単位。担当・期間・コストを個別に割り当てられる粒度まで分解する点が、スケジュールとコストの管理可能性を左右するため重要。
- ワークフロー(workflow)
- .github/workflows/ 配下に置く YAML ファイルで定義する自動化プロセス。on: でトリガーを宣言し、1 つ以上のジョブを実行する。
- ワークフローコマンド
- ログのアノテーション(::notice::/::warning::/::error::)、秘密値のマスク(::add-mask::)、ログの折りたたみ(::group::)など、ランナーと対話する特殊な出力コマンド。
- ワークフロー自動化(Defender for Cloud)
- セキュリティアラートや推奨事項をトリガーに Logic Apps を起動し、通知・チケット起票・修復などの対応を自動化する。
- ワークロード ID フェデレーション
- 外部の ID プロバイダー(IdP)が発行する OIDC 等のトークンを、クラウド側の信頼設定で検証し、短命な資格情報に交換することで長期のシークレットやパスワードなしにアクセスを得る汎用の仕組み。Azure DevOps のサービス接続、GitHub Actions、GCP、AWS の OIDC フェデレーションなど各クラウド・CI/CDで同様の仕組みが実装されている。Azure では、この交換によりロール割り当て済みのサービスプリンシパルやマネージド ID のトークンを得る形になる(AWS の「ロールを引き受ける」とは仕組みが異なる)。
- ワーニエ法
- 入力データ構造に着目し、集合論的な観点からプログラム構造を導く設計技法。データが「いつ・どこで・何回」現れるかを繰返しの入れ子として括弧で階層的に表現し、順次・選択・繰返しの3つの制御構造を組み合わせてプログラムをトップダウンに組み立てる。入力と出力の両データ構造の対応を扱うジャクソン法と対比される。システムアーキテクトがデータ構造主導で処理を設計する際に用いる。
- ワイルドカード(グロブ)
- シェルがファイル名をパターンで展開する仕組み。* は0文字以上の任意文字列、? は任意の1文字、[a-c] は集合/範囲。正規表現の * とは意味が異なる。
- ワイルドカードマスク
- ACLやOSPFのnetworkコマンドで、対象アドレス範囲を指定するために使うビットマスク。サブネットマスクとは0/1の意味が逆で、0のビットは一致必須、1のビットは任意(don't care)を表す。多くの場合サブネットマスクを反転した値になる。
- ワイルドカード権限
- ポリシーの Action や Resource に "*"(例:s3:*)を使い、想定より広い操作やリソースを許可してしまう記述。最小特権の原則に反する典型パターンで、IAM Access Analyzer のポリシー検証やアクセスアドバイザーで過剰な許可を検出・是正する。
- ワンホットエンコーディング
- カテゴリ変数を、各カテゴリに対応する 0/1 のフラグ列へ変換する手法。順序のないカテゴリ(色・地域)に使い、ラベルエンコーディング(整数化=誤った順序を与える)の代わりに用いる。次元が増えるため高カーディナリティでは別手法(埋め込み等)を検討。
- 暗号の危殆化
- 計算機の性能向上や解読手法の進歩により、かつて安全とされていた暗号方式や鍵長が、実用的な時間で解読可能になってしまう現象。危殆化した方式(例:鍵長の短いRSAや古いハッシュ関数)を使い続けると解読・改ざんのリスクが高まるため、より強度の高い方式へ計画的に移行できる備え(クリプトアジリティ)が必要になる。
- 暗号化
- データを鍵で変換し許可された者だけが復号できるようにする技術。対称鍵/非対称鍵、保管時/転送時がある。
- 暗号化シークレットと変数(secrets / vars)
- 機密値はシークレット(secrets.<名前>)、非機密の設定値は変数(vars.<名前>)として保存する。組織/リポジトリ/環境の 3 レベルにスコープでき、同名は狭いスコープ(環境>リポジトリ>組織)が優先。REST API で管理(書き込みは公開鍵で暗号化)。
- 暗号鍵(GMEK / CMEK / CSEK)
- GMEK=Google が管理する既定の鍵、CMEK=顧客が Cloud KMS で管理する鍵(ローテーション/無効化を制御)、CSEK=顧客が鍵そのものを供給。保存時・転送時とも既定で暗号化される。
- 暗黙のdeny(ACL)
- ACLの末尾に明示的なエントリがなくても自動的に存在する、すべての通信を拒否する規則。管理者が許可条件を1つも定義しなければ、そのACLを適用したインタフェースの通信が意図せず全て遮断されるため、必要な通信をpermitで明示的に許可し忘れないことが重要。
- 位置パラメータ($#/$@/shift)
- スクリプトに渡された引数を参照する特殊変数。$0 はスクリプト名、$1〜$n は各引数、$# は引数の個数($0 は含まない)、$*/$@ は全引数。shift は引数を1つ左へずらす。
- 依存関係(パッケージ)
- あるパッケージが動作するために必要な別のパッケージ。apt/yum は依存関係を自動で解決してまとめて導入するが、dpkg/rpm は解決せず、依存が欠けるとエラーになる。
- 依存関係グラフ
- マニフェスト/ロックファイルを解析し、リポジトリが依存するパッケージと推移的依存を一覧化する機能。Dependabot アラートや Dependency Review の基盤になる。
- 委譲バイパス / 委譲例外
- Push Protection 等のブロックやポリシーを、承認制で一時的に回避/例外扱いできる仕組み。誰が承認できるかをアクセス管理で統制し、記録して監査可能にする(恒久免除ではない)。
- 委託事業者と中小受託事業者
- 中小受託取引適正化法(旧・下請法)における取引当事者の呼称。発注する側が委託事業者、受注する中小企業が中小受託事業者で、2026年1月の法改正・名称改定に伴い旧称の「親事業者」「下請事業者」から改められた。委託事業者には代金支払遅延の禁止など優越的地位の濫用を防ぐ義務が課される。
- 委託先管理
- 業務やシステム開発・運用を外部に委託する際、委託先が自組織と同等以上のセキュリティ水準を維持しているかを、契約(秘密保持契約・SLA)・選定時の評価・定期監査を通じて確認・管理すること。委託先経由の情報漏えいやサプライチェーン攻撃を防ぐ目的で行う。
- 委任管理者(Delegated administrator)
- GuardDuty・Config・Security Hub 等、対応サービスの組織全体にわたる管理権限を、管理アカウント以外のメンバーアカウントへ委任する仕組み。管理アカウントの操作を最小化し、セキュリティ運用チームなどへ職務分離した権限を与えられる。サービスごとに個別設定が必要。
- 委任権限とアプリケーション権限(API アクセス許可)
- 委任(delegated)権限はサインインユーザーの代理として動きユーザーの権限を超えない。アプリケーション権限はユーザー無しでアプリ単独で動き強力なため管理者同意が必須。バックグラウンドのデーモンはアプリケーション権限を使う。
- 意味的等価性
- リファクタや近代化の前後で挙動が変わっていないこと。テストで確認し、「動く別物」になっていないかを防ぐ。
- 異常検出(anomaly detection・Power BI)
- 時系列の外れ値を自動検出し説明候補を示す分析機能。予測(将来推定)とは目的が異なる。
- 移行戦略(7 つの R)
- ワークロードごとに選ぶ移行アプローチの分類。リホスト(無変更)/リプラットフォーム(小最適化)/リファクタ(作り替え)/リパーチェス(SaaS 化)/リタイア(廃止)/リテイン(据え置き)/リロケート(そのまま移設)。労力と価値のトレードオフで選ぶ。
- 移行戦略(lift-and-shift / lift-shift-migrate)
- lift-and-shift は OS/DB を変更せず Azure VM へ再ホストする最小変更の移行。lift-shift-migrate to HANA は移行と同時に DB を SAP HANA へ転換/最適化する。要件とダウンタイム許容度で使い分ける。
- 移行戦略(リフト&シフト/改善移行/リファクタ)
- リフト&シフト=そのまま移行(最速・変更最小)、改善して移行=少し最適化、リファクタリング=クラウドネイティブに作り替え(手間大・効果大)。要件で選ぶ。
- 移行方式(ビッグバン・段階移行・並行運用)
- 旧システムから新システムへ切り替える進め方。一斉移行(ビッグバン)は全機能・全拠点を一度に切り替える方式で、期間が短くコストは低いが失敗時の影響が全体に及びリスクが高い。段階移行は機能や拠点を部分ずつ切り替える方式で、リスクを分散できるが移行期間が長く新旧併存の管理が要る。並行運用は新旧を一定期間同時に稼働させ結果を突合して検証する方式で、確実性は高いが二重の運用コストがかかる。システムアーキテクトは業務停止許容度とリスク許容度から方式を選定する。
- 一貫性
- ACID特性の一つで、トランザクションの実行前後でデータベースが定義された制約(一意性制約や参照整合性など)を常に満たしていることを保証する性質。矛盾したデータ状態への遷移を防ぎ、業務データの正しさを維持する。
- 一貫性レベル(Cosmos DB)
- 読み取りがどれだけ最新かを定める 5 段階。強い順に strong(常に最新・MRW 不可)、bounded staleness(K 操作/T 時間まで遅延許容)、session(同一セッション内整合・既定)、consistent prefix(順序保証)、eventual(最弱・最速・最安)。SDK のクエリで弱める方向にのみ上書き可。
- 一時認証情報
- STS が発行する短命の認証情報(アクセスキー・シークレットキー・セッショントークンの 3 点)。期限切れで自動失効するため、埋め込みの長期キーより漏洩リスクが低い。
- 引用符(シングル/ダブル/バッククォート)
- シングルクォート '…' はすべて文字どおり(変数展開しない)、ダブルクォート "…" は $変数 を展開、バッククォート `…`(=$(…))はコマンド置換で出力に置き換わる。
- 運用環境(Production)
- 本番の業務アプリ/フローを置くための環境。Dataverse を持ち、目的やチームごとに分けて作るのが基本。
- 運用監視ツールとアラート
- サーバーやサービスの死活・リソース使用率・応答時間を継続的に監視し、しきい値超過などの異常時に管理者へ通知(アラート)する仕組み。Nagios・Icinga2・Zabbix・Cacti・MRTG・collectd などのツールがあり、SNMP でネットワーク機器の状態を取得するものも多い。
- 影響分析(ダウンストリーム依存)
- レイクハウス/ウェアハウス/データフロー/セマンティックモデルの変更が、下流のレポート等にどう波及するかを事前に把握する分析。
- 音声合成(TTS)と SSML
- テキストを自然な音声に変換する音声合成。SSML(音声合成マークアップ言語)で発音・抑揚・間を制御し、カスタムニューラル音声で独自の声を作れる。
- 音声認識(STT)とカスタム音声
- 話し言葉をテキストに変換する音声認識。専門用語や訛りに合わせて「カスタム音声認識(Custom Speech)」で認識精度を高められる(音声合成側のカスタムニューラル音声とは別物)。
- 音声翻訳と話者認識
- 音声をその場で別言語の音声/テキストへ変換する音声翻訳と、声で個人を識別/検証する話者認識。
- 仮想テーブル(Dataverse)
- 外部システムのデータを Dataverse にコピーせず、データプロバイダー経由でその場で取得・表示する仮想的なテーブル。標準の Dataverse テーブルと同様にモデル駆動型アプリやリレーションシップで扱えるが、実データは外部に残るためストレージ容量を消費しない。
- 仮想ネットワーク(VNet)
- Azure内に作るプライベートなネットワーク。サブネットで区切り、ピアリングでVNet同士をつなぐ。
- 仮想ネットワークフローログ
- 通過/拒否トラフィックを Storage に記録するログ(NSG フローログの後継)。Traffic Analytics で可視化し、通信の傾向や異常を分析する。
- 仮想ハブ(Virtual WAN)
- Virtual WAN の中核となるマネージドのハブ。VPN/ExpressRoute/P2S ゲートウェイや接続を収容し、ハブルーティングでスポーク間も中継する。
- 仮想ファイルシステム(/proc・/sys)
- ディスク上に実体を持たず、カーネルがメモリ上で生成して見せる情報の窓口。/proc はプロセス・カーネル状態(/proc/cpuinfo 等)、/sys(sysfs)はデバイスツリーを公開する。
- 仮想ホスト
- 1台の Web サーバーで複数のドメイン(サイト)を同時にホストする仕組み。Apache や nginx でドメインや IP・ポートごとに設定を分けて、それぞれ別サイトとして応答させる。
- 仮想マシン(VM)
- ハイパーバイザー上で動く、独立したゲスト OS(カーネルを含む)を持つ仮想的なコンピュータ。ホストと異なる OS も動かせるが、起動が遅くリソース消費も大きい。
- 仮想マシンイメージ
- OS やアプリケーションをあらかじめ設定した状態でパッケージ化したイメージファイル。これをもとに同一構成の仮想マシンを短時間で複製・起動でき、スケールアウトやマシン再構成に使う。
- 仮想マシンスケールセット(VMSS)
- 同一構成のVMを束ねて負荷に応じ自動スケールする仕組み(性能の軸。可用性は可用性セット/ゾーン)。
- 仮想化
- 1台の物理的なコンピュータ上に、複数の仮想的なコンピュータ(仮想マシン)をソフトウェア的に作り出す技術(サーバ仮想化)。ストレージ・ネットワーク・デスクトップなども同様に仮想化できる。ハードウェア資源を効率的に活用でき、集約や柔軟な構成変更が可能になる。
- 仮想記憶とページング
- 主記憶の容量を超えるプログラムを実行可能にする技術。プログラムを一定サイズの「ページ」に分割し、必要なページだけを主記憶に読み込み、不要になったページを補助記憶へ追い出す(ページング方式)。
- 仮名加工情報と匿名加工情報
- どちらも個人情報保護法上の加工類型だが目的が異なる。仮名加工情報は他の情報と照合しない限り本人を識別できないよう加工したもので、事業者内部での分析利用を想定し本人同意なく目的外利用の制限が一部緩和される一方、第三者提供は原則禁止。匿名加工情報は特定の個人を識別できず復元も不可能な状態まで加工したもので、本人同意なく第三者提供が可能。
- 可観測性の三本柱(メトリクス・ログ・トレース)
- メトリクス(Cloud Monitoring・数値の傾向)、ログ(Cloud Logging・出来事)、トレース(Cloud Trace・リクエストの経路)。トレース ID でログとトレースを相関させて原因を特定する。
- 可観測性の三本柱(メトリクス/ログ/トレース)
- システムの内部状態を外から把握する3要素。メトリクス=数値の時系列(傾向・アラート)、ログ=個々の出来事の記録(原因調査)、トレース=1リクエストの経路と遅延(ボトルネック特定)。AWS では CloudWatch+X-Ray が担う。
- 可逆圧縮と非可逆圧縮
- 可逆圧縮は元のデータを完全に復元できる圧縮方式。非可逆圧縮は人間が知覚しにくい情報を間引くことでより高い圧縮率を実現するが、元のデータへ完全には戻せない(画質や音質がわずかに劣化する)。
- 可視性(Public/Private/Internal)
- リポジトリの公開範囲。Public=誰でも、Private=許可者のみ、Internal=同じ Enterprise 内。
- 可視性タイムアウト
- SQS で受信中のメッセージを一定時間ほかの消費者から隠す仕組み。処理が可視性タイムアウトを超えるとメッセージが再表示され二重処理が起きうるため、処理時間に合わせて設定する。
- 可用性セット(障害/更新ドメイン)
- 単一データセンター内で VM を障害ドメイン(電源/ネットワーク/ラック)と更新ドメイン(計画メンテの単位)に分散し、計画外障害と計画メンテの同時影響を避ける。データセンター規模の障害には可用性ゾーンを使う。
- 可用性ゾーン
- リージョン内で物理的に分離したデータセンター(独立電源/冷却/NW)。ゾーン冗長で高可用性を実現。
- 可用性ゾーン vs 可用性セット(SAP HA)
- 可用性ゾーンは別データセンターに配置しゾーン(DC)障害に耐える。可用性セットは同一 DC 内の障害/更新ドメインで分離する。SAP の HA 要件に応じて使い分ける。
- 可用性テスト
- 外部から定期的にエンドポイントへアクセスして稼働と応答時間を監視するテスト(Application Insights)。従来の URL ping テストは廃止方向で、標準テストやカスタム TrackAvailability が現行。失敗時にアラートを出す。
- 可用性管理(サービスマネジメント)
- ITサービスが利用者の必要とするときに使える状態を維持することを目的とした管理活動。稼働率(アベイラビリティ)を目標値どおりに保てるよう、単一障害点の排除・冗長化・保守計画などを設計・監視する。稼働率は MTBF ÷(MTBF+MTTR)で表され、故障間隔を延ばし修復時間を短縮することで向上する。
- 可用性管理(サービスマネジメントの)
- 合意した目標可用性を満たすようサービスと構成品目を設計・測定・改善する活動。稼働率は平均故障間隔と平均修復時間から稼働率=MTBF÷(MTBF+MTTR)で求め、直列構成では各要素の可用性の積、並列(冗長)構成では1−(1−a)のn乗で全体の可用性を評価する。単一障害点(SPOF)を排除して冗長化することが設計の要点となる。ITサービスマネージャは目標可用性を監視し、冗長化の投資対効果を判断する。
- 稼働率
- システムが正常に稼働している時間の割合。稼働率=MTBF÷(MTBF+MTTR) で求められ、故障間隔が長く修復時間が短いほど高くなる。可用性の代表指標で、SLA の合意値(例 99.9%)としても用いる。
- 課金アカウントと予算
- 費用を支払う単位。プロジェクトをリンクして使う(1 アカウントに複数プロジェクト可)。予算とアラートはしきい値で通知するのみで自動停止はしない。
- 課金モデル(年間/月次コミット)
- サブスクリプションの支払い頻度と契約期間の組み合わせ。年間コミット・月次支払いは中途解約に違約金が生じ、月次コミットは割高だが柔軟。CSP 経由では新価格制度(NCE)でこの選択が明確化されている。
- 過学習(オーバーフィッティング)
- 訓練データには高精度だがテストデータでは精度が落ちる現象(高バリアンス)。モデルが訓練データのノイズまで学習しすぎている状態で、正則化(L1/L2)・ドロップアウト・データ追加/拡張・早期終了などで抑える。バイアス-バリアンスのトレードオフの一端。
- 画像(コントロール)
- 画像を表示するコントロール。固定画像のほか、カメラで撮影した写真やデータソースの画像を表示できる。
- 画像分析(タグ・キャプション・物体検出)
- Azure AI Vision の画像分析。視覚的特徴を選んで画像にタグ付け・キャプション生成・物体検出を行い、スマートクロップで重要領域を切り出す。
- 画面(スクリーン)
- キャンバスアプリの 1 ページ分の表示単位。コントロールを配置し、画面間を移動(ナビゲーション)してアプリを構成する。
- 会議テンプレート(meeting templates)
- 特定の会議シナリオ(例:ウェビナー的な社内イベント、面接)向けに、既定の会議オプション(誰が発表者か、ロビーの扱い、録画可否等)をひな型として事前定義できる機能。管理者がテンプレート内の設定をロックすれば、主催者が変更できないよう強制できる。用途に応じたテンプレートを Teams 管理センターで作成・割り当てる。
- 会議のカスタマイズ ポリシー(meeting customization policies)
- Teams Premium で提供される、会議の見た目・ブランディングを制御するポリシー(Teams 管理センター「会議」>「カスタマイズ ポリシー」)。組織のロゴ・ブランドカラー・カスタム画像からなる「会議テーマ」(ポリシーごとに最大5個)と、参加者が使えるカスタム会議背景画像(同50枚まで)をテナントまたはユーザー単位で指定する。会議で使える機能(録画・チャット等)を制御する通常の meeting policies とは目的が異なり、外観のみを扱う。
- 会議ポリシー(meeting policies)
- 録画・文字起こし・ロビー・画面共有・参加者権限など会議の機能をユーザー単位で制御する。定型の meeting templates、見た目の meeting customization policies とは別。
- 会社法と金融商品取引法
- 会社法は、株式会社をはじめとする会社の設立・組織・運営・機関設計(株主総会・取締役会等)や、計算書類の作成・開示など、会社に関する基本的なルールを定める法律。金融商品取引法(金商法)は、有価証券の発行・流通や金融商品取引業を規制し、投資家保護や公正な市場を確保するための情報開示(有価証券報告書等)や内部統制報告制度(J-SOX)を定めている。両法は上場企業のガバナンスや情報開示のあり方に密接に関わり、企業のコンプライアンス・内部統制設計の前提となる。
- 会話言語理解(CLU)
- ユーザー発話から意図(インテント)とエンティティを抽出するカスタム言語モデル。発話を追加して学習・評価・デプロイし、クライアントから利用する(旧 LUIS の後継)。
- 会話履歴 / セッションメモリ
- マルチターン対話で文脈を保つために過去のやり取りを保存・参照する仕組み。DynamoDB 等に保持し、毎回プロンプトへ要約・関連分のみ渡してコンテキスト超過を避ける。Bedrock Agents はセッション単位でメモリを扱う。
- 回帰
- 教師あり学習で、連続的な数値を予測する(例:価格・気温)。
- 回帰分析
- 説明変数(原因)と目的変数(結果)の関係を数式でモデル化し、説明変数から目的変数を予測・分析する統計手法。説明変数が1つの単回帰分析と複数の重回帰分析があり、多くは最小二乗法で誤差の二乗和を最小化する回帰係数を求める。
- 回収期間法(投資回収期間)
- 投資額を、その投資から生まれる年々のキャッシュフローで回収するまでに要する期間(年数)によって投資案を評価する方法。計算が単純で分かりやすい一方、単純回収期間法は貨幣の時間価値(割引)を考慮せず、回収後に生じる長期的な大きなリターンも評価に反映されないため、NPVやIRRと併用して判断するのが望ましい。時間価値を考慮する場合は割引後の回収期間(割引回収期間法)を用いる。
- 回復性
- 障害が発生してもシステムが機能を維持し、あるいは速やかに復旧できる性質。冗長化やクラスタ構成、地理的分散などによって高められる。
- 改ざん防止(tamper protection)
- Microsoft Defender for Endpoint の設定。ローカル管理者権限を持つマルウェアや攻撃者であっても、リアルタイム保護の無効化・シグネチャ更新の停止・Defender の削除といったセキュリティ設定変更をブロックする。Intune のセキュリティ設定管理経由でテナント全体に配布・強制するのが一般的。
- 改善勧告(指摘事項)
- 監査人が発見した内部統制の不備について、その事実・原因・影響(リスク)を明らかにした上で、被監査部門に改善を促す提言。監査人はあくまで改善を勧告するにとどまり、統制の具体的な設計や実施そのものは被監査部門が行う。監査人が自ら是正策を実行すると、独立性を損なうため避けなければならない。
- 開発チーム(スクラム)
- スクラムでスプリントゴール達成に必要な作業を自己組織的にこなす作り手。2020年版スクラムガイドでは独立した下位チームとしての「開発チーム」は廃止され、プロダクトオーナー・スクラムマスターと共に単一の「スクラムチーム」を構成する「開発者(Developers)」と再定義された。外部から作業を割り当てられず、スプリントバックログの実現方法は開発者自身が計画・分担する。設計・実装・テストを内包する職能横断性が特徴。
- 開発者ポータル(APIM)
- API の利用者向けに、ドキュメント・試用・サブスクリプション取得を提供する自動生成ポータル。
- 開発者環境(Developer)
- 個人が無償で使える学習・開発用の環境(旧コミュニティプラン)。自分専用で機能を試せる。
- 階層(セマンティックモデル)
- 年→四半期→月や国→都市など、ドリルダウンできる段階構造をモデルに定義したもの。レポートで掘り下げ表示に使う。
- 階層パーティションキー
- 最大 3 階層(例 テナント→ユーザー→セッション)でデータを分割し、論理パーティションの 20GB 制限を超えてスケールしつつ上位プレフィックスでの効率的なクエリを可能にするパーティション設計。単一キーで偏る場合の合成パーティションキーとは目的が異なる。
- 外部キー
- 別テーブルの主キーを参照してテーブル間を関連づける列。参照整合性を保つ。
- 外部データラッパー(FDW)(postgres_fdw/file_fdw/CREATE SERVER/USER MAPPING/FOREIGN TABLE)
- 外部データソースを通常のテーブルのようにSQLで扱う仕組み。postgres_fdw は他のPostgreSQLサーバへ、file_fdw はCSV等のファイルへの接続用拡張。CREATE SERVER で接続先を定義し、CREATE USER MAPPING でローカルロールと外部の認証情報を紐付け、CREATE FOREIGN TABLE で実際に問い合わせ可能な外部テーブルを定義する。
- 外部ユーザー(B2B ゲスト)
- Microsoft Entra ID に、相手organizationの既存 ID のままゲストとして登録されるユーザーオブジェクト。招待を承諾するとテナント内にユーザーオブジェクトが作成され(UserType=Guest)、条件付きアクセスやライセンス割り当ての対象にできる。B2B コラボレーション機能によって作成される実体で、ロール グループのような権限委任の単位とは別物。
- 外部結合
- 結合条件に一致しない側の行も、対応する列を NULL として結果に含める結合。左外部結合・右外部結合・完全外部結合があり、「注文のない顧客も含めて一覧化する」といった要件で使う。
- 外部設計と内部設計
- 外部設計は、利用者から見える画面・帳票・データ項目・処理の流れなど、システムの「外から見える仕様」を決める工程。内部設計は、外部設計を実現するためのプログラム内部の構造やモジュール分割・データ構造など、開発者側の「内側の仕様」を決める工程。外部設計→内部設計→プログラム設計の順に詳細化していく。
- 拡張イベント(Extended Events)
- 軽量なイベント収集の仕組み。SQL トレースの後継で、デッドロックや長時間クエリなどを低オーバーヘッドで診断する。
- 拡張ネットワーキング(ENA / EFA)
- 高スループット・低遅延の通信機能。ENA(Elastic Network Adapter)=最大100Gbps級。EFA(Elastic Fabric Adapter)=HPC/機械学習の密結合計算向けに OS バイパスで超低遅延を実現。
- 確約利用割引(CUD)と継続利用割引(SUD)
- CUD=1〜3年の利用を約束して受ける割引(安定利用向け)。SUD=契約なしに長く使うほど自動で適用される割引。
- 確率影響度マトリクス
- リスクの発生確率と影響度を軸にした表にリスクをマッピングし、優先度(高/中/低)を判定する定性的リスク分析の手法。限られた対応資源をどのリスクに優先配分すべきかを判断する基礎として重要。
- 確率的生成
- LLM が確率的に出力を生成する性質。同じ文脈でも出力が揺れ、常に最適とは限らない(不具合ではない)。
- 確率統計
- データの傾向や不確かさを数値で捉える分野。2つのデータの関連の強さを表す相関、傾向を式で近似する回帰、平均を中心に左右対称の釣鐘型に分布する正規分布などがあり、データ分析や品質管理の基礎になる。
- 楽観ロック
- 更新時にバージョン番号やタイムスタンプを比較し、他者による変更が無かった場合のみ書き込みを成功させる競合制御方式。事前にロックを取らないため並行性が高く、DynamoDBの条件付き書き込み(ConditionExpression)が代表的な実装。競合検出時はリトライで解決する。
- 割り当てフィルター
- グループ割り当ての上に重ねて、OS バージョンなどの属性に合うデバイスだけにポリシー/プロファイルを適用するよう絞り込む仕組み。
- 割込み遅延(レイテンシ)
- 割込み要求が発生してから、対応する割込みサービスルーチン(ISR)が実際に実行を開始するまでの時間。割込み禁止区間の長さや多重割込みの優先度設計に左右され、リアルタイムシステムではこの遅延の最悪値(ワーストケース)を見積り、デッドラインを満たせるかを検証する必要がある。
- 活性化関数と損失関数
- 隠れ層は ReLU(勾配消失に強い・死んだ ReLU には Leaky ReLU/GELU)。出力層は課題で選ぶ:回帰=線形+MSE、2 値=sigmoid+バイナリ交差エントロピー、多クラス(排他)=softmax+カテゴリカル交差エントロピー、多ラベル(非排他)=各出力 sigmoid。softmax は合計 1 になるため多ラベルには不適。最適化は SGD/Momentum/RMSProp と既定の Adam。
- 完成時総コスト見積り(EAC)
- EVMでプロジェクト完了時点の総コストを予測する指標。現在のコスト効率が今後も継続すると仮定した場合、EAC=BAC(完成時総予算)÷CPIで算出する。CPIが1未満(コスト超過傾向)ならEACはBACより大きくなり、予算超過が見込まれる。
- 完全バックアップ
- 対象データすべてを毎回まるごと複製するバックアップ方式。リストアは単純で速いが、実行のたびに時間・容量を要する。差分・増分バックアップの基準点としても使われる。
- 完全読み込みと増分読み込み
- 完全読み込みは毎回すべてを入れ替える方式、増分読み込みは前回以降の変更分だけを取り込む方式(ウォーターマークや CDC を使う)。大量データでは増分が効率的。
- 感情分析とオピニオンマイニング
- テキストの肯定/否定/中立をスコア付けする感情分析と、対象(側面)ごとの意見を抽出するオピニオンマイニング。
- 環境(Environment)
- 学習/推論の依存関係(Python パッケージ・Docker イメージ・conda)を固定する再現性の単位。キュレーション済みかカスタムを選べる。
- 環境(environment)と保護ルール
- デプロイ先を表す単位。必須レビュアーによる承認、待機タイマー、デプロイ可能ブランチの制限、環境スコープのシークレット/変数を設定でき、本番デプロイを承認制にできる。
- 環境(Power Platform)
- アプリ・フロー・Dataverse データを入れる分離されたコンテナ。部門別や Dev/Test/本番の分離に使い、各環境は固有のセキュリティ境界を持つ。
- 環境と承認/ゲート(Azure Pipelines)
- デプロイ先(Dev/Test/Staging/Prod)を表す環境と、そこへのデプロイを統制するチェック。承認(人手のサインオフ)、ゲート(監視クエリ等の自動チェック)、ブランチ制御、ビジネスアワー、必須テンプレートなどを組み合わせて本番リソースを保護する。
- 環境の種類
- 用途別の環境タイプ。既定(テナント自動作成)・運用(本番)・サンドボックス(試験/リセット可)・開発者(個人用)・試用(期間限定)など。
- 環境変数(Power Platform)
- 環境ごとに値を切り替えられる設定値。ソリューションに含めて移送し、開発→本番で接続先や URL などを書き換えずに変えられる。
- 監査の品質管理
- 監査業務そのものの品質を確保するための仕組み。監査調書の査閲(レビュー)、監査人から独立した立場による審査、監査基準への準拠状況の確認などを通じて、監査手続の妥当性や監査意見の根拠が十分であることを担保する。個々の監査人の判断のばらつきを抑える役割を持つ。
- 監査モジュール法(組込監査モジュール)
- 本番プログラムの内部にあらかじめ監査用の処理機能(特定条件に合致する例外取引の抽出・記録など)を組み込んでおき、システムが稼働している間、継続的に監査証拠を収集するCAATの一技法。リアルタイムかつ継続的な監視が可能な一方、本番プログラムの改修を伴うため導入・保守のコストと統制が課題となる。
- 監査リスク(audit risk)
- 監査人が重要な不備を見逃し、誤った結論を報告してしまうリスク。固有リスク・統制リスク・発見リスクの積として捉えられ、監査人は固有リスクと統制リスクの評価結果に応じて監査手続の範囲や深さ(発見リスクの水準)を調整し、監査リスク全体を許容水準まで抑える。
- 監査ログ(Fabric)
- 誰がいつ何をしたか(アクセス・変更・共有等)を記録するログ。Purview/管理ポータルで確認し、コンプライアンスや調査に使う。
- 監査ログイベント(Copilot)
- ポリシー変更やアクセスなどの操作を「誰が・いつ・何を」追跡する仕組み。コードの内容を保存するものではない。
- 監査ログとサインインログ
- ユーザーや管理者の操作を記録する監査ログと、認証イベントを記録するサインインログ。誰がいつ何をしたかを追跡し、調査やトラブルシューティングに使う。
- 監査ログと稼働統計の設定(log_statement/track_functions/track_activities)
- 監査ログの中核は log_statement で、どのSQL文をログへ記録するか(none/ddl/mod/all)を制御する。一方 track_functions(関数呼び出し統計の収集)と track_activities(pg_stat_activity へ現在実行中クエリを記録するか)は厳密には監査ログ機能ではなく稼働統計・監視のための設定であり、log_statement とは区別して理解する。
- 監査ログのストリーミング
- 監査ログ(誰が・いつ・何を)を SIEM など外部基盤へ継続的に転送し、横断分析・長期保管・早期検知に使う仕組み。
- 監査意見
- 保証型のシステム監査において、監査人が入手した監査証拠に基づき、監査対象の内部統制やシステムの適正性・有効性について表明する結論。意見は監査人が実際に収集した監査証拠の範囲内でのみ表明されるべきであり、根拠のない断定や証拠を超えた保証はしてはならない。意見の類型には無限定適正意見・限定付適正意見・不適正意見・意見不表明があり、証拠の制約や重要な不備の有無に応じて使い分ける。
- 監査技法と可監査性
- 監査技法は、システム監査人が監査証拠を収集するための手法で、ヒアリング、ドキュメントレビュー、現地調査(視察)、チェックリスト法、そしてコンピュータ支援監査技法(CAAT、監査用ソフトやテストデータを用いる手法)などがある。可監査性は、システムが監査を受け入れられるように、処理過程やアクセスの記録(ログ・監査証跡)が整備されている性質を指す。
- 監査計画
- システム監査を実施する前に、監査の目的・対象範囲・実施時期・手続・体制などを定めた計画。監査資源を効果的に配分するため、リスクの大きい領域を優先する中長期計画(基本計画)と、個別監査ごとの詳細な個別監査計画に分けて策定されることが多い。
- 監査手続
- 監査人が監査証拠を入手するために実施する具体的な手法・作業の総称。監査計画に基づき、監査目的に応じてドキュメントレビュー法・インタビュー法・現地調査法・CAATなどの技法を組み合わせて選択し、実施結果を監査調書に記録する。
- 監査手続書(監査プログラム)
- 設定した監査目標を達成するために、どの監査手続をどのような順序・方法で実施するかを具体的に記した計画文書。担当する監査人が交代しても一定の監査品質を保つための実務上の指針となり、実施結果は監査調書として記録される。監査手続書は監査範囲・監査目標に基づいて作成される。
- 監査証拠(十分性と適切性)
- システム監査人が監査意見を形成する根拠となる情報。十分性は証拠の量、適切性は証明力(関連性と信頼性)を指し、両者を満たして初めて監査意見の合理的な裏付けとなる。監査人自らが直接入手した証拠や被監査部門の外部から得た証拠は、被監査部門から間接的に入手した証拠より一般に信頼性が高いと判断される。
- 監査証跡
- 誰がいつ何をしたかを後から追跡できる記録。AWS では CloudTrail が API 呼び出しを記録し、改ざん検知やインシデント調査に使う。
- 監査証跡(オーディットトレイル)
- 取引やシステム処理が発生してから最終的な結果に至るまでを、記録をたどることで追跡できるようにした一連の履歴。ログや伝票番号などが連鎖することで、処理の発生から集計・出力までを双方向に追跡でき、監査人は不正や誤りの原因究明、処理の正当性確認に利用する。
- 監査人の独立性
- システム監査人が被監査部門や監査対象システムの開発・運用に利害関係を持たず、公正かつ客観的に判断できる立場を保つべきという原則。外観上の独立性(第三者から見て疑念を持たれない立場)と精神上の独立性(自らの判断が影響を受けない姿勢)の両方が求められる。
- 監査調書と査閲
- 監査調書とは、監査人が実施した監査手続の内容や入手した監査証拠を記録した文書。監査意見の根拠を裏付ける重要な記録であり、監査終了後も一定期間保管する義務がある。査閲とは、作成された監査調書について、担当者とは別の上位者が内容の妥当性・網羅性を確認するレビュー活動であり、監査の品質を担保する仕組みの一つ。
- 監査範囲と監査目標
- 監査目標は監査を通じて何を確かめるか(例:可用性の妥当性、内部統制の有効性)を示し、監査範囲は対象とする情報システム・業務プロセス・期間・拠点などの境界を示す。監査人はまず監査目標を明確にし、その達成に必要十分な監査範囲を画定したうえで監査計画を立てる。監査範囲が目標と整合していないと、結論の裏付けが不十分になる。
- 監査報告書
- システム監査の実施結果を依頼者(経営者等)に報告する文書。監査の目的・範囲、実施した監査手続、発見事項(指摘事項)、改善勧告、監査意見を記載する。監査人は事実に基づく指摘と、実施した手続の範囲を明確に区別して記述する必要がある。
- 監視データの種類(フルパケットキャプチャ・セッション・トランザクション・メタデータ・アラート)
- フルパケットキャプチャはペイロードまで含む全内容を保存し詳細だが容量が大きい。セッションデータ(NetFlow等のフローデータ)はフロー単位の要約(誰と誰がいつ・どれだけ・どのポートで通信したか)を記録する。トランザクションデータはHTTPリクエストやDNSクエリなどアプリケーション層のやり取りそのものの記録。メタデータは通信そのものではなく付随する属性情報。アラートデータはIDS/IPS等が検知結果として生成する通知。目的に応じてどのデータ型を参照すべきかを判断する。
- 監視と最適化(Query Store・DMV・自動チューニング)
- まず計測してボトルネックを特定する。Query Store=クエリ履歴・実行プラン・待機統計を保持し劣化(リグレッション)検出やプラン強制(plan forcing)に使う。動的管理ビュー(DMV)=待機統計やブロッキング等の「今この瞬間」の内部状態を SQL で参照。実行プランでスキャン vs シーク・キールックアップ・非 SARGable を見て、インデックス(不足の作成/未使用削除/断片化の再構成)と統計更新で改善。Azure SQL の自動チューニング(推奨インデックスの自動適用・FORCE LAST GOOD PLAN)とインテリジェントクエリ処理が下支えする。
- 監視ハブ(Monitoring hub)
- パイプライン/ノートブック/Spark などの実行履歴・状態・所要時間を一覧で確認する Fabric の監視画面。
- 管理グループ
- 複数のサブスクリプションを束ねる最上位コンテナ。ポリシーやアクセス制御を一括適用し下位へ継承。
- 管理プレーン
- 機器の設定・監視・ソフトウェア更新など、運用者が機器そのものを管理するための通信を扱う機能面。SSH/HTTPS/SNMP/NETCONF等がこのプレーンを通る。転送規則を決める制御プレーンや実際のパケット転送を行うデータプレーンとは役割が異なり、管理プレーンへの不正アクセスは機器全体の乗っ取りに直結するため、アクセスの制限が特に重要になる。
- 管理策の4分類(技術的・物理的・人的・組織的管理策)
- リスクアセスメントで特定されたリスクに対する対策(管理策)を性質で分類したもの。技術的管理策はアクセス制御や暗号化などシステム・機器による対策、物理的管理策は施錠や入退室管理など空間・設備による対策、人的管理策は教育や誓約書など従業員の行動・意識に関わる対策、組織的管理策は規程整備や体制構築など組織のルール・体制に関わる対策を指す。単独では実効性が乏しく、複数を組み合わせる多層防御によって初めて機能する。
- 管理者同意ワークフロー
- ユーザーがアプリの権限を申請し、管理者が審査・承認する仕組み。危険な権限へのユーザー同意を抑え、同意フィッシングのリスクを下げる。同意ポリシーと組み合わせて運用する。
- 管理図(品質)
- プロセスの測定値を時系列にプロットし、管理限界線(上方・下方)を用いて工程が安定しているかを判定する図。7点連続で片側に出るなどの非ランダムなパターンを異常と判定し、統計的にプロセスを制御して是正の要否を判断する点で重要。
- 管理単位(administrative units)
- Entra ロールの適用範囲を、特定のユーザー/グループ/デバイスのサブセットに限定する仕組み。例:地域 IT に自地域のユーザーだけ Password Administrator を委任。テナント全体ロールと異なり範囲を絞り最小特権を保つ。
- 関係モデル
- データを行(タプル)と列(属性)からなる表(関係)の集合として表現するデータモデル。E.F. コッドが提唱し、関係代数・関係論理という数学的基盤に基づいて問合せの意味を厳密に定義できる。
- 関係代数
- 関係(表)を対象に、選択・射影・結合・和・差・直積・商などの演算を定義した数学的な問合せ言語。SQL の問合せは内部的にこの関係代数の演算に変換され、オプティマイザが等価な演算列に書き換えて実行計画を作る。
- 関数インデックス(式インデックス)
- 列そのものではなく式や関数の計算結果を索引化するインデックス(例:CREATE INDEX ... ON t (lower(col)))。lower(email) = 'x' のような、素の列インデックスでは対応できない検索を高速化できる。
- 関数従属
- 属性Aの値が決まれば属性Bの値が一意に決まる関係(A→B)。正規化の理論的基礎で、主キーの一部にのみ従属する部分関数従属を解消すると第2正規形、主キー以外の非キー属性を介して間接的に従属する推移的関数従属を解消すると第3正規形が得られる。
- 基数変換(2進数・16進数)
- ある基数で表した数を別の基数の表記に変換する操作。コンピュータ内部は2進数で処理するが、桁が長くなるため4桁ずつまとめて16進数で簡潔に表記することが多い(2進1111=16進F)。10進→2進は商が0になるまで2で割り剰余を逆順に並べ、2進→10進は各桁に重み(…8,4,2,1)を掛けて合計する。
- 基盤モデル
- 幅広い用途に使える大規模な事前学習モデル(例:GPT)。マルチモーダルは複数種類を扱う。
- 基本ファイル操作(cp/mv/rm/mkdir)
- ファイル・ディレクトリを操作する基本コマンド。cp コピー、mv 移動(=名前変更)、rm 削除、mkdir/rmdir はディレクトリの作成/空ディレクトリの削除、touch は空ファイル作成/時刻更新、file は種類判定。ディレクトリごとの操作には -r(再帰)が要る。
- 揮発性データ
- 電源が切れたり時間が経過すると消えてしまうデータ(レジスタ・キャッシュ・実行中プロセス・ネットワーク接続状態・メモリ内容等)。フォレンジック調査ではディスク上の永続データより先に、失われやすい揮発性データから優先して収集する(揮発性順の収集)。
- 既知の誤り(KEDB)
- 根本原因または回避策が判明した問題を「既知の誤り」と呼び、それらを蓄積した情報基盤が既知の誤りデータベース(KEDB)である。KEDBを参照することでサービスデスクや技術チームは既知の障害に対する回避策を即座に適用でき、インシデントの迅速な回復に役立つ。
- 既定エディタ(EDITOR/nano/emacs)
- crontab -e 等が起動するエディタは環境変数 EDITOR で決まる(export EDITOR=nano)。nano は画面下に操作が常時表示され初心者向き、emacs も代表的なエディタ。
- 既定環境(Default)
- テナント作成時に自動で 1 つ用意される環境。全ユーザーがアクセスでき、個人的な試作に使われやすい。本番用途には専用環境の作成が推奨。
- 期待金額価値(EMV)
- リスクが発生した場合の金銭的影響額に発生確率を乗じて算出する定量的リスク分析の指標(EMV=確率×影響額)。複数のリスクシナリオを金額換算して比較できるため、デシジョンツリー分析などでどの選択肢が期待値上有利かを判断する基礎になる。
- 期待値
- 確率変数が取り得る各値に、その値が発生する確率を掛けて合計した値。E(X)=Σ(x_i×p_i)で求め、試行を多数回繰り返したときの結果の平均的な見込みを表す。意思決定の期待利得の比較や、品質管理・保険料算定など幅広い分野で用いられる。
- 機械学習(ML)
- データから規則(パターン)を学び、新しいデータに対して予測を行う技術。AIの土台。
- 機器冗長と経路冗長
- 機器冗長は同一機能を持つ機器を複数台配置し(VRRP/HSRP等による仮想ゲートウェイ、電源・ファンの二重化等)、1台の故障時も他方に自動切替して稼働を継続する構成。経路冗長は物理的に異なる複数の伝送路(回線・スイッチ経路)を用意し、1経路の障害時にルーティングプロトコルやSTP等が代替経路へ自動的に切り替える構成。両者は独立した観点で、機器単体の可用性と経路(リンク)単体の可用性をそれぞれ担保する。
- 機能安全
- 電子・電気システムの誤動作や故障が発生しても、検出・制御機構によって重大な事故につながる状態を防ぐという考え方、およびその実現手法の総称。ハードウェア故障だけでなくソフトウェアの不具合も対象とし、リスクの大きさに応じた安全度水準(SIL/ASIL)を定めて、要求される信頼性のレベルに応じた設計・検証を行う。
- 機能要件
- システムが「何をするか」を定めた要件。たとえば「商品を検索できる」「注文を登録できる」といった、利用者が使う具体的な機能のこと。性能や安全性など品質面を定める非機能要件と対になる。
- 機密 VM(Confidential VM)
- 使用中のメモリ(処理中データ)をハードウェアベースで暗号化し、最高レベルの分離を提供する VM。Azure Virtual Desktop のセッションホストで機微なワークロードを保護する。起動完全性を高める Trusted Launch(セキュアブート+vTPM)とは別の保護層。
- 機密ディスク暗号化と二重暗号化
- 機密 VM のディスクを仮想化ベースで保護する機密ディスク暗号化に加え、プラットフォームキーと顧客キーの二層で守る二重暗号化を構成できる。
- 機密データ保護(PII / マスキング)
- PII(個人を特定できる情報)や PHI などの機密データを守る運用。Macie で検出・分類し、暗号化・アクセス制御・最小化で保護。マスキング/トークン化で値を秘匿し、データ分類に応じて扱いを変える。ログへの機密混入も防ぐ。
- 規制コンプライアンス(標準・カスタム標準)
- Defender for Cloud の規制コンプライアンスダッシュボードで、PCI DSS や ISO 等の標準への準拠状況を評価し、独自要件はカスタム標準として追加できる。
- 規模の経済(クラウドの価値)
- AWS が多数の顧客の需要を束ねることで単価が下がり、その分が値下げとして還元される考え方。使った分だけ支払う従量課金、初期投資不要、グローバル展開の容易さと並ぶクラウドの基本価値。
- 記憶階層
- 速度・容量・コストが異なる記憶装置を階層的に組み合わせ、全体として高速かつ大容量に見せる構成。上位ほど高速・小容量・高コストで、レジスタ→キャッシュメモリ→主記憶→補助記憶(SSD・ハードディスク)の順に配置する。CPUと主記憶の速度差はキャッシュメモリで、主記憶の容量不足は仮想記憶で補う。
- 記憶装置(HDD・SSD)
- プログラムやデータを長期間保存しておく装置(補助記憶装置)。HDDは磁気ディスクを回転させて読み書きする装置で大容量・低価格が特徴。SSDはフラッシュメモリを使い、可動部が無いため高速・静音・耐衝撃だが同容量ではHDDより高価な傾向がある。
- 起動テンプレート
- AMI・インスタンスタイプ・ユーザーデータ・ネットワーク等の起動設定をひとまとめにしたバージョン管理可能な定義。Auto Scaling や Spot で使う。旧来の起動設定(launch configuration)はレガシー。
- 飢餓状態
- 優先度に基づくスケジューリングにおいて、優先度の低いプロセスやタスクが優先度の高いものに割り込まれ続け、いつまでもCPUや資源を割り当てられない状態。エージングにより優先度を徐々に引き上げることで防止できる。
- 偽陽性・偽陰性・真陽性・真陰性(アラートの判定)
- アラートの正誤を評価する4分類。真陽性(TP)は実際に脅威があり正しくアラートが出た場合。真陰性(TN)は脅威がなく正しくアラートが出なかった場合。偽陽性(FP)は脅威がないのにアラートが出てしまう誤検知で、多いとアナリストの疲弊(アラート疲れ)を招く。偽陰性(FN)は実際の脅威をアラートが検知できず見逃した場合で、最も危険な判定ミス。
- 技術のSカーブ
- 技術の性能や普及率が時間とともに、緩やかな立ち上がり(黎明期)から急速な向上(成長期)を経て頭打ち(成熟・限界期)に至るという、S字型の曲線を描くという考え方。既存技術が成熟し限界に近づくと改良への投資対効果が急激に低下するため、ストラテジストはSカーブ上の位置を見極め、次世代技術への乗り換え(技術の非連続な転換)に投資すべきタイミングを判断する材料として用いる。
- 技術ロードマップ
- 将来の技術動向や自社の技術開発計画を時間軸に沿って図示したもの。MOT(技術経営)において、研究開発投資の意思決定や事業戦略との整合を図る際に用いる。
- 擬似言語(科目B)
- 基本情報技術者試験の科目Bで用いられる、特定のプログラミング言語に依存しない記述形式。変数宣言・条件分岐・繰り返し・関数呼び出しなどを共通の構文で表し、アルゴリズムのトレースや穴埋めを問う。
- 競争戦略
- 競合他社に対して自社が優位に立つための戦略の総称。市場・競合を分析するSWOT分析・5フォース分析・PPM、自社の中核的強みを軸とするコアコンピタンス経営などの手法を用い、コスト優位や差別化によって持続的な競争優位の確立を目指す。
- 共通フレーム(SLCP)
- ソフトウェアの企画から開発・運用・保守・廃棄に至るライフサイクル全体の作業内容と用語を共通化し、発注者と受注者が同じ理解で取引できるようにした「ものさし」となる枠組み(SLCP-JCF、共通フレーム)。個々の作業をプロセス・アクティビティ・タスクとして体系化し、契約範囲や責任分担を明確化するが、具体的な作業手順や方法論そのものは規定しない。システムアーキテクトは要件定義や設計の取引・分担を共通フレームの用語で整理し、認識齟齬を防ぐ。
- 共通鍵暗号方式
- 暗号化と復号に同じ鍵(共通鍵)を使う暗号方式。処理は高速だが、通信相手ごとに鍵を安全に共有する必要があり、相手が増えるほど鍵管理が煩雑になる。
- 共有(Power BI)
- 特定の個別アイテムを少数の相手へ渡す配布手段。多数へ整理して配布するアプリや開発のワークスペースロールと使い分ける。
- 共有コンピューターのライセンス認証(SCA)
- マルチセッションのセッションホストで Microsoft 365 Apps を正しくアクティベーションするための設定。複数ユーザーが同じ VM を共有する環境で必要で、有効化しないとアクティベーションに失敗する。
- 共有リンク
- OneDrive/SharePoint で最新の 1 つのコピーを、権限(閲覧/編集・社内限定・期限付き等)を設定して共有する仕組み。添付の複製を避ける。
- 強化学習
- 報酬と罰を通じて試行錯誤で良い行動(方針)を学ぶ機械学習。例:ロボット制御・ゲーム。
- 強制アクセス制御(MAC)
- 情報や利用者に付与された機密区分(ラベル)に基づき、システムが一元的にアクセス可否を強制する方式。情報の所有者であってもポリシーに反して権限を緩められない。所有者の裁量に任せる任意アクセス制御(DAC)と対をなす。
- 強制トンネリングとゲートウェイトランジット
- 強制トンネリング=外向きインターネットを UDR でオンプレ経由に強制する。ゲートウェイトランジット=スポークがハブの VPN/ExpressRoute ゲートウェイを共有する設定。
- 強整合性(strong consistency)
- 書き込み完了後の読み取りは必ず最新の値を返す整合性モデル。結果整合性より遅延やコストが増えがちだが、在庫数や残高のように古い値の読み取りが許されない場面で選ぶ。整合性モデルはこのトレードオフに基づき用途ごとに使い分ける。
- 教師あり学習
- 正解(ラベル)付きデータで学ぶ方式。回帰(数値予測)と分類(カテゴリ予測)がある。
- 教師なし学習
- 正解なしのデータから構造を見つける方式。代表はクラスタリング(グループ化)。
- 脅威アクター
- 攻撃を実行する主体の分類。愉快犯・技術力の低いスクリプトキディ、政治的主張を目的とするハクティビスト、金銭目的の組織的犯罪集団、国家の支援を受けAPT攻撃を行う国家的アクター、正規の権限を悪用する内部関係者(インサイダー)などに分けられ、能力や目的により防御側の優先度判断が変わる。
- 脅威と脆弱性
- 脅威は情報資産に損害を与える可能性のある要因(不正アクセス・災害・人的ミスなど)を指し、脆弱性はその脅威につけ込まれる情報資産側の弱点(設定不備・パッチ未適用・管理体制の不備など)を指す。リスクは「脅威が脆弱性を突いて損害が生じる可能性」として両者の組み合わせで捉え、脆弱性をなくせば脅威が存在してもリスクは顕在化しにくくなる。
- 脅威の3分類(人的脅威・技術的脅威・物理的脅威)
- 情報セキュリティにおける脅威を発生源で分類したもの。人的脅威は内部不正や誤操作・過失など人間に起因するもの、技術的脅威はマルウェアや不正アクセスなど技術的手段によるもの、物理的脅威は災害や盗難・破壊など物理的な被害によるもの。SGでは特に人的脅威(内部不正・過失)が管理対象として重視される。
- 脅威モデリング
- アプリやシステムの設計段階で「どこが・どう攻撃されうるか」を体系的に分析する手法。business-critical なアプリの脅威を洗い出し、対策を設計へ織り込む(DevSecOps のシフトレフトの一部)。
- 脅威防御と脅威インテリジェンス
- 攻撃の検知・分析・対応を支える仕組み。Microsoft Defender XDR が複数の領域のシグナルを統合し、拡張検知と対応(XDR)を提供する。
- 凝集度(cohesion)
- 一つのモジュール内の要素がどれだけ単一の目的に向けてまとまっているかを表す尺度で、高いほど良い設計とされる。弱い順から暗合的凝集<論理的凝集<時間的凝集<手続的凝集<通信的凝集<逐次的凝集<機能的凝集で、機能的凝集(単一の機能だけを担う)が理想である。システムアーキテクトはモジュール分割時に各モジュールが高凝集となるよう責務を整理し、保守性と再利用性を高める判断を行う。
- 業務プロセスのモデリング
- 日々の業務の流れを図で目に見える形に表す作業。図式化にはフローチャートのほか、標準記法で描くBPMNや、データの流れに着目するDFD(データフロー図)などが使われる。誰が・何を・どの順番で行うかを共有して関係者の認識をそろえ、無駄や問題点を見つけやすくし、業務改善やシステム化の前提となる。
- 業務モデリング
- システム化の対象となる業務の流れや構造を可視化・整理する分析工程。DFD(データフローダイアグラム)やフローチャート・業務フロー図などの構造化手法に加え、データ構造にはE-R図、オブジェクト指向ではUMLのアクティビティ図・ユースケース図なども用いる。業務要件を明確化し、後続のデータモデリングやシステム設計の入力とする。
- 均一バケットレベルアクセス
- Cloud Storage で、オブジェクトごとの ACL を使わずバケット単位で IAM により権限を一元管理する推奨設定。簡潔で安全。
- 近接配置グループ(PPG)
- VM を物理的に近接配置し、アプリ↔DB 間のネットワーク遅延を最小化する Azure の配置機能。SAP の遅延要件を満たすために使う。可用性ゾーン(DC 障害耐性)とは目的が異なる。
- 刑法(電子計算機損壊等業務妨害罪)
- コンピュータや電磁的記録を損壊・改ざんし、あるいは虚偽の情報や不正な指令を与えて、コンピュータを使用目的に沿った動作をさせない、または使用目的に反する動作をさせることで人の業務を妨害する行為を処罰する刑法の規定。マルウェア感染によるシステム破壊やデータ改ざんで業務を妨げた場合にもこの規定が適用されうる。
- 形式保持暗号化(FPE)と仮名化
- 形式保持暗号化(FPE)は元の桁数/形式を保ったまま暗号化し互換性を維持する。仮名化は値を一貫した代替値に置換し再識別を防ぎつつ解析を可能にする。単純マスキング(不可逆な隠蔽)と使い分ける。
- 形態素解析
- 自然言語処理において、文を意味を持つ最小単位(形態素)に分割し、それぞれに品詞などの情報を付与する処理。日本語は英語と異なり単語間にスペースがないため、辞書と文法規則に基づいて単語境界を判定する形態素解析が構文解析など後段の処理の前提となる。
- 経営組織
- 企業が事業を遂行するために編成する組織の形態。業務内容ごとに部門を分ける職能別組織、製品・地域などの単位で自己完結的に編成する事業部制組織、職能軸と事業軸を格子状に組み合わせるマトリックス組織などがあり、事業戦略や規模に応じて選択される。
- 経路冗長化
- 単一の回線・機器の障害がネットワーク全体の到達性喪失に直結しないよう、宛先への経路を複数確保する設計手法。動的ルーティングによる代替経路への自動切替や、等コストの複数経路を用いたロードバランシングと組み合わせて可用性を高める。
- 継続トークン(continuation token)
- 大きなクエリ結果をページ分割し、次のページの取得位置を引き継ぐトークン。ページネーションで効率的に続きを取得する。同時実行制御の ETag とは別物。
- 継続的アクセス評価(CAE)
- トークンの有効期限を待たず、危険な変化(アカウント無効化・場所変化・リスク上昇)でセッションを即時に失効させる仕組み。従来のトークン寿命依存と異なり、侵害後の遮断を素早くする。
- 継続的サービス改善(CSI)
- KPIやメトリクスの測定結果をもとに、サービスとプロセスを継続的に見直し改善していく取組み。現状測定・目標との差分分析・改善策の実施・効果確認をPDCAとして繰り返す。サービスマネージャは思いつきの改善ではなく、データに基づいて改善対象の優先順位を判断し、小さな改善を積み重ねてサービス価値を継続的に高める。なお「CSI(継続的サービス改善)」はITIL v3の専用ライフサイクル段階の用語であり、ITIL4では独立した段階ではなく指針原則・実践としての『継続的改善(Continual Improvement)』へ発展的に統合されている。
- 計算グループ
- 同じロジック(前年比・累計など)を複数メジャーへ一括適用する仕組み。メジャーの重複を減らし保守を楽にする。Tabular Editor で作る。
- 計算テーブル
- DAX 式で生成するテーブル。日付テーブルやパラメーター表など、ソースにない補助テーブルを作るのに使う。
- 計算量とオーダ記法(O記法)
- アルゴリズムの処理時間や必要な記憶量が入力サイズnに対してどう増加するかを表す指標。O(1)・O(log n)・O(n)・O(n log n)・O(n^2)のように表記し、アルゴリズムの効率比較に用いる。
- 計算列(DAX)
- 行ごとに事前計算してモデルに保存する列。メジャーと違い保存されるためモデルが肥大化しやすい。原則はソース側/メジャーで代替を検討。
- 軽量AP(Lightweight AP)
- それ自体では設定を保持せず、WLCからCAPWAPトンネル経由で常時制御・設定配布を受けて動作するアクセスポイント。単体のIPアドレスを設定するだけでよく、多数拠点への大規模展開・一元管理に向く。自律型APと対比される。
- 決定木
- 特徴量に対するしきい値で分岐を繰り返し、葉ノードで予測値を出す解釈しやすいモデル。単体では訓練データに過剰適合しやすく、深さの制限や剪定で抑える必要がある。回帰・分類の両方に使える。
- 結果整合性(eventual consistency)
- 書き込み直後は古い値が読まれる可能性があるが、時間の経過とともに全レプリカが最終的に収束する整合性モデル。高可用性・低遅延を優先する分散データストアの既定挙動になっていることが多い。強整合性が不要な読み取りに使うことでスループットを稼げる。
- 結合戦略(Nested Loop / Hash Join / Merge Join)
- プランナが選ぶ主要な結合方式。Nested Loop は外側の少数行に対し内側をインデックス等で効率的に探索する方式で小規模結合に有利。Hash Join は等価結合専用で、片方をハッシュテーブル化し総当たりを避ける。Merge Join は両側がソート済み(または安価にソートできる)前提でマージ的に結合する。index/sortedness が選択の主要因になる。
- 結合度(coupling)
- モジュール間の依存の強さを表す尺度で、低いほど良い設計とされる。強い順(悪い順)から内容結合>共通結合>外部結合>制御結合>スタンプ結合>データ結合で、データ結合(必要なデータだけを引数で渡す)が最も望ましい。良い設計は高凝集かつ低結合であり、システムアーキテクトはインタフェースを最小化して変更の波及を局所化する設計判断を下す。
- 結合度と強度(モジュール分割の指標)
- モジュール分割の良否を測る2つの指標。結合度はモジュール間の依存の強さ(内容結合が最悪〜データ結合が最良)、強度はモジュール内の要素の関連の強さ(暗合的強度が最悪〜機能的強度が最良)。低結合・高強度な分割が保守性の高い設計とされる。
- 堅牢な FM API 統合
- FM の API を本番品質で組み込む設計。ストリーミング/非同期で体感とスループットを上げ、スロットリングには指数バックオフ+リトライ、X-Ray で分散トレース、エラーログと検証で切り分け、疎結合(イベント駆動)で障害を局所化する。
- 検疫ネットワーク
- 持ち込みPCなどを業務ネットワークから隔離した領域に一旦接続させ、ウイルス対策やパッチ適用の状況を検査したうえで、問題がなければ初めて業務ネットワークへの接続を許可する仕組み。管理外端末からの感染拡大を防ぐ。
- 検査制約(CHECK制約)
- 列や行が満たすべき条件を SQL の式で宣言し、条件を満たさない値の挿入・更新を DBMS が拒否する制約。「在庫数は0以上」のような業務ルールをアプリ側でなくデータベース側で強制できる。
- 検索修飾子(qualifiers)
- is:/label:/author:/assignee: など、検索を種類・状態・担当などで絞り込むキーワード。複数は AND。
- 検索層の診断(RAG の品質切り分け)
- RAG の回答品質が低いとき、原因を検索層で切り分ける運用。埋め込みの適合、データドリフト、チャンク戦略、検索の再現率/適合率、メタデータフィルタを順に点検し、生成側(プロンプト/モデル)と区別して直す。
- 検証(validity check)
- 検出されたトークンが今も有効(active)かを発行元 API 等で確認し、高信頼な秘密を優先してアラートする仕組み。失効済みやダミーに振り回されず優先順位付けを効かせる。
- 検証済み作成者(verified creator)
- GitHub が検証したアクション作成者。利用ポリシーで「GitHub 製+検証済み」のアクションのみ許可、といった統制に使う。
- 検定(仮説検定)
- 標本データをもとに、母集団に関する仮説が統計的に妥当かどうかを判断する手法。否定したい仮説を帰無仮説、採用したい仮説を対立仮説として立て、帰無仮説が正しいと仮定したときの観測結果の起こる確率(p値)を有意水準と比較し、p値が有意水準より小さければ帰無仮説を棄却する。判断の誤りには、正しい帰無仮説を棄却する第一種の過誤と、誤った帰無仮説を採択する第二種の過誤がある。
- 権限の反復的絞り込み(最小特権の運用)
- 最初は広めに許可して動かし、Access Analyzer の未使用アクセスや CloudTrail の実利用、Access Advisor の最終アクセス情報をもとに不要な権限を継続的に削る運用サイクル。生成されたポリシーで安全に絞り込む。
- 権限昇格
- 攻撃者や不正なプロセスが、本来割り当てられている以上の権限(一般ユーザーから管理者権限など)を不正に獲得する行為。OSやアプリの脆弱性、設定不備を突いて行われ、獲得後はシステム全体への影響力を持つため深刻度が高い。
- 権力・関心度グリッド
- ステークホルダを権力(影響力の大きさ)と関心度(プロジェクトへの興味の強さ)の2軸でマッピングし、エンゲージメント戦略を決める分析ツール。権力大・関心大の層には密接な管理が必要など、限られたコミュニケーション労力の配分先を判断する基礎として重要。
- 鍵管理のライフサイクル(生成・保管・更新・廃棄)
- 暗号鍵を安全に運用するための一連のプロセス。①生成=十分な強度の鍵を安全な方法で作成、②保管=HSM等での安全な保管により秘密鍵の漏えいを防止、③更新(ローテーション)=定期的に鍵を新しくし漏えい時の被害範囲を限定、④廃棄=不要になった鍵を復元不可能な形で確実に削除、の4段階からなる。秘密鍵が漏えいすると、それを使った暗号化・署名すべての信頼性が失われるため、特に保管段階の管理策が重要となる。
- 鍵配送問題
- 共通鍵暗号では、通信当事者が同じ鍵を安全に共有する必要があるが、その鍵自体を安全に届ける手段が別途必要になるという課題。公開鍵暗号を用いて共通鍵(セッション鍵)を暗号化して配送する、あるいはDiffie-Hellman鍵交換で通信路上に鍵そのものを流さずに共有するハイブリッド方式でこの問題を解決する。
- 現地調査法(視察)
- 監査人が実際に業務現場やシステム運用の場に赴き、自らの目で状況を観察して確かめる監査技法。文書やインタビューでは把握しきれない実態(作業手順の遵守状況、物理的なアクセス管理の実施状況など)を直接確認でき、監査人自身が入手する証拠として信頼性が高い。
- 限界利益と限界利益率
- 限界利益は、売上高から変動費を差し引いた金額(限界利益=売上高-変動費)で、固定費の回収と利益の源泉となる。限界利益率は売上高に対する限界利益の割合(限界利益率=限界利益÷売上高)で、損益分岐点売上高=固定費÷限界利益率(=固定費÷(1-変動費率))の算出に用いられる。限界利益率が高い製品・事業ほど、売上増加が利益に寄与しやすい。
- 限定公開クラスタと承認済みネットワーク
- GKE のセキュリティ設計。限定公開クラスタはノードに外部 IP を持たせず非公開にし、承認済みネットワーク(または DNS ベースのエンドポイント)でコントロールプレーンの管理元 IP を限定する。
- 個人情報保護法
- 氏名・生年月日など特定の個人を識別できる情報を扱う事業者に対し、利用目的の特定・適正な取得・安全管理措置・本人同意のない第三者提供の制限などを義務付ける法律。
- 固定IP
- 特定のインスタンス(サーバー)に紐づけられ、変更されない IP アドレス。インスタンスが入れ替わっても IP を引き継げるフローティングIPとは対照的。
- 固定割当とリース
- 固定割当はDHCPサーバがMACアドレスなどのクライアント識別子とIPアドレスを対応付けて常に同一アドレスを払い出す方式で、サーバ機器などアドレス固定が必要な端末に用いる。リースは動的割当において貸与するIPアドレスに設定される有効期限で、期限が近づくとクライアントは(ユニキャストの)DHCPREQUESTで更新要求を行い(リース期間の1/2でT1更新・7/8でT2再バインド)、期限切れ後は再取得が必要となる。
- 固定費と変動費
- 総費用を売上高(生産量)との関係で分解した2区分。地代家賃や固定給のように売上高の増減にかかわらず一定額発生する費用が固定費、原材料費や出来高給のように売上高に比例して増減する費用が変動費。損益分岐点分析やCVP分析の基礎となる。
- 固有リスク(inherent risk)
- 内部統制が存在しないと仮定した場合に、業務やシステムの性質そのものから本来的に存在するリスク。取引の複雑さや金額規模、技術的な新しさなどに起因し、監査人が統制の有無とは切り離して評価する所与のリスクである。固有リスクが高い領域ほど、監査人は監査資源を重点的に配分する。
- 故障パターン
- システムで想定される障害の類型(物理障害・論理障害、単一障害点の破損など)。HA構成の設計では、どの故障パターンでもサービスが継続できるよう冗長化を検討する。
- 顧客管理キー(CMK)/ プラットフォーム管理キー(PMK)
- 保存時暗号化の鍵の管理方式。PMK=Azure が既定で管理(追加設定なし)。CMK=顧客が Key Vault で鍵を作成・ローテーション・失効を制御し、Storage や SQL TDE の保護キーに指定する(規制対応など)。暗号アルゴリズム自体は同じで、違いは「鍵を誰が管理するか」。ディスクは Azure ディスク暗号化(ゲスト OS 内 BitLocker/DM-Crypt)やホストでの暗号化(基盤側)で保護し、いずれも CMK 対応。
- 後処理(post-processing)
- モデルが生成した後に、形式の整形や不要・不適切な出力の除去を行い、最終提案として返す段階。
- 誤り制御
- 伝送中に発生するビット誤りを検出・訂正するための機構で、パリティチェックやCRC(巡回冗長検査)による誤り検出と、ハミング符号などによる誤り訂正(FEC)、および誤り検出時に再送を要求するARQ方式に大別される。イーサネットフレームはFCS(CRC)で誤り検出のみを行い、誤り訂正・再送は上位層(TCP等)に委ねる設計となっている。
- 誤差逆伝播
- ニューラルネットワークの学習で、出力の誤差を出力層から入力層へ逆向きに伝えながら各重みの勾配を計算する手法。勾配降下法と組み合わせて重みを更新するために使われ、深層学習の学習アルゴリズムの中核をなす。
- 候補キーとスーパーキー
- スーパーキーはタプルを一意に識別できる属性集合全般。候補キーはその中で、これ以上属性を削ると一意性を失う最小のスーパーキー。主キーは候補キーの中から選ばれた代表であり、選ばれなかった候補キーは代替キー(alternate key)と呼ぶ(人工的に付与する代理キー(surrogate key)とは別概念)。
- 公開鍵暗号(非対称)
- 公開鍵で暗号化し秘密鍵で復号する(または秘密鍵で署名し公開鍵で検証する)方式。鍵共有問題を解決し、TLS・SSH・コード署名・証明書の基盤になる。共通鍵(対称)より遅いため、実データは対称鍵で暗号化しその鍵を公開鍵で保護する(エンベロープ)。
- 勾配ブースティング
- 弱い決定木を1本ずつ逐次的に追加し、直前までの予測誤差を縮めるように学習していくアンサンブル手法(代表実装は XGBoost・LightGBM)。表形式データに対する強力な既定手法として、多くのマネージド ML サービスに組み込みアルゴリズムとして用意されている。
- 勾配降下法
- 損失関数の勾配(傾き)の反対方向へ、学習率で決まる歩幅ずつパラメータを更新して損失を最小化する最適化アルゴリズム。全データを使うバッチ型のほか、1件ずつ更新する確率的勾配降下法(SGD)や少量ずつ処理するミニバッチ型などの変種がある。
- 工数(人月・人日)
- ある作業を完了するのに必要な仕事量を、人数と期間を掛け合わせて表した見積りの単位。1人が1か月で行う量を1人月といい、開発の規模や費用を見積もる基礎になる。ただし人手を増やしても期間が比例して短くなるとは限らない点に注意する。
- 攻撃シミュレーション トレーニング
- 擬似的なフィッシング メールを送ってユーザーを訓練する教育機能。実際に届いた脅威を調査する Threat Explorer とは目的が別。
- 攻撃ストーリー(インシデントグラフ)
- Defender XDR で、多段階・多ドメイン・横移動を含む複雑な攻撃の侵入→横移動→持ち出しの連鎖を可視化する機能。エンティティ中心に全体像を素早く把握でき、Security Copilot の要約と併用する。
- 攻撃ベクトル
- 攻撃者がシステムやネットワークへ不正に侵入・攻撃するために利用する経路や手段。フィッシングメール、脆弱なパスワード、パッチ未適用のソフトウェア、USBメモリなど、攻撃の「入り口」となるものを指す。
- 攻撃対象領域(アタックサーフェス)
- 攻撃者が侵入や攻撃に利用できる可能性のある、システム上の入り口・経路の総体。稼働中のサービス・開いているポート・公開されたAPI・ユーザー入力欄などが多いほど攻撃対象領域は広がり、不要な機能を停止するハードニングによって縮小できる。
- 攻撃面の減少(ASR)ルール
- ランサムウェアや悪用の常套手段(Office の子プロセス生成・難読化スクリプト・資格情報窃取等)をブロックする Defender for Endpoint の予防的な設定。監査モードで影響を確認してからブロックモードへ段階展開する。
- 更新の種類(feature updates / quality updates)
- Windows Update の更新を目的別に分類したもの。feature updates は新機能を含む年1回程度の大型更新(旧 OS バージョンからの移行に相当)、quality updates はセキュリティ修正やバグ修正を含む月例(毎月第2火曜=パッチ チューズデー中心)の更新。更新リングではこの2種類を別々に延期日数設定できる。
- 更新リング(Intune)
- Windows Update for Business の設定をポリシー化し、デバイス グループごとに更新の展開タイミング(延期日数)や再起動の猶予期間を段階的に分けて適用する仕組み。先行リング(IT/パイロットグループ)で問題を検出してから広域リングへ展開することで、不具合更新の影響範囲を限定できる。
- 更新可能ビューとWITH CHECK OPTION
- 単一テーブルからの単純な射影・選択で定義されたビューは、実テーブルへの更新として書き戻せる(更新可能ビュー)。WITH CHECK OPTION を付けると、ビューの定義条件から外れるような更新・挿入を拒否し、ビュー越しの整合性を保つ。
- 更新系 DML(INSERT/UPDATE/DELETE)
- 表の行を追加・更新・削除する DML 文。INSERT は新しい行を挿入し、UPDATE ... WHERE のように条件を指定して既存行の列値を変更し、DELETE は条件に合う行を削除する。トリガー内では変更前後の行を OLD/NEW で参照できる。
- 構成プロファイル(configuration profiles)
- 複数の Teams デバイスに言語・タイムゾーン・表示などの共通設定を一括適用する仕組み。場所/用途でグルーピングする device tags とは別。
- 構成管理
- 成果物・文書・ベースラインのバージョンを識別・記録し、承認された変更のみを反映して整合性を保つ活動。統合変更管理と連携し、どの版が正式なベースラインかを常に一意に追跡できるようにする点で重要。
- 構成管理(サービスマネジメントの)
- サービスを構成する構成品目(CI)を識別・記録・管理し、CI間の相互関係を把握する活動。正確な構成情報を維持することで、変更やリリースの影響分析、インシデントの原因追跡、可用性設計の根拠となる。財務価値の把握を主目的とするIT資産管理とは目的が異なり、構成管理はサービス提供に必要な関係と状態の正確さを主眼とする。ITサービスマネージャは構成情報の正確さと鮮度を保つ統制を設計し、他の管理活動がそれを信頼して判断できる状態を維持する。
- 構成管理ツール
- サーバーの設定やソフトウェア構成をコード化し、複数台へ一貫して適用・管理するツール(Ansible 等)。ステートレスな構成でのマシン再構成やスケールアウトを支える。
- 構成品目(CI)
- 構成品目(CI)は、構成管理の対象として個別に識別・管理される構成要素で、ハードウェア・ソフトウェア・文書・サービスなど多様な粒度を取り得る。各CIは属性(種別、版数、状態など)を持ち、他のCIとの相互関係を通じてサービス構成を形づくる。ITサービスマネージャはどこまでをCIとして管理するか(管理粒度)を設計し、細かすぎて維持できない状態と、粗すぎて影響分析に使えない状態の均衡を判断する。
- 構成変数(リポジトリ/環境/組織変数)
- 機密でない設定値をリポジトリ・環境・組織レベルで定義し vars コンテキストで参照する仕組み。秘匿値はシークレットを使う(変数は値がログに見えうる)。
- 構造化データ
- 行と列の固定スキーマを持つデータ。型が定まり検索・集計が高速。例:リレーショナルDBのテーブル。
- 行(レコード)
- テーブルの 1 件分のデータ。各列に値を持つ。旧称レコード。
- 行レベルセキュリティ(Fabric)
- 利用者ごとに見える「行」を制限するデータ単位のセキュリティ。ウェアハウス/SQL 分析エンドポイント/セマンティックモデルで述語により行を絞る。
- 行レベルセキュリティ(RLS)
- セキュリティ述語(関数)でユーザーごとに見える行を制限する。テナント分離や担当範囲の制御に使う。
- 行動規範(Code of conduct)
- コミュニティ参加者に期待する振る舞いと違反時の対応を定めた文書。CONTRIBUTING(貢献手順)やライセンスとともに健全な OSS 運営を支える。
- 購入モデル(vCore / DTU)
- vCore は CPU・メモリ・ストレージを個別に選べる柔軟なモデルで、Azure Hybrid Benefit や予約割引が使える(推奨)。DTU は計算・ストレージをまとめた簡易指標。
- 高可用性(HA)
- 障害があってもサービスを動かし続けられるように設計すること(冗長化・可用性ゾーンなど)。
- 高度なハンティング(KQL)
- Defender XDR / Sentinel で KQL を使い、横断的なテレメトリから脅威を能動的に探索する。クエリを分析ルール化して自動検知につなげる。
- 合成パーティションキー
- 複数フィールドを連結(例 tenantId-date)したり、ランダムサフィックスを付けてカーディナリティを上げるパーティションキー。単一フィールドでは分散が偏る場合に使う。多レベル分割の階層パーティションキーとは別の手法。
- 合成モニタ
- エンドポイントやワークフローを能動的に定期チェックし、ユーザー視点で外形監視する仕組み。受動的な監視と併用して問題を先回りで検知する。
- 混合インスタンスポリシー
- 1 つの Auto Scaling グループで複数インスタンスタイプとオンデマンド/スポットの比率を組み合わせる設定。スポット中断に強く、容量確保とコスト削減を両立する。
- 差分バックアップ
- 直近の完全バックアップ以降に変更されたデータだけを複製するバックアップ方式。リストアには完全バックアップ1回+最新の差分1回で済むが、日を追うごとに差分のサイズが増えていく。
- 再帰(再帰呼び出し)
- 関数が自分自身を呼び出す処理方式。問題をより小さな同種の問題に分解して解く際に用いる(例:階乗計算、木構造の走査)。終了条件(基底部)を欠くと無限に呼び出しが続く。
- 再帰と分割統治法
- 再帰は関数が自分自身を呼び出す処理形式で、基底条件に到達するまで問題をより小さな同種の部分問題に置き換えて解く。分割統治法は問題を独立した部分問題に分割し、それぞれを再帰的に解いてから結果を統合するアルゴリズム設計手法で、クイックソートやマージソート、高速フーリエ変換などに用いられる。再帰は実装手段、分割統治法はアルゴリズム設計戦略という関係にある。
- 再帰問い合わせと反復問い合わせ
- 再帰問い合わせは、問い合わせを受けたDNSサーバが最終的な回答(または存在しないことの確認)を得るまで代理で他サーバへ問い合わせを続け、依頼元には最終結果のみを返す方式。反復問い合わせは、問い合わせを受けたサーバが自身の知る範囲で最善の回答(多くは他サーバへの参照)を返し、後続の問い合わせは依頼元自身が行う方式。一般にスタブリゾルバからキャッシュサーバへは再帰、キャッシュサーバから権威サーバへは反復で行われる。
- 再試行ポリシー
- 一時的な障害(ネットワーク瞬断など)に対し、アクティビティを自動で再実行する設定。失敗パスと組み合わせて堅牢化する。
- 再利用アセット(.pbit / .pbids)
- .pbit=Power BI テンプレート(モデル/レイアウトのひな形)、.pbids=データソース接続定義。共有して同じ構成を再利用する。
- 最終ゲートウェイ(gateway of last resort)
- 経路表内に宛先に一致するより限定的な経路が1つもない場合に、代わりに使われるデフォルトルート(0.0.0.0/0)の転送先。静的に設定するか、動的ルーティングプロトコルから配布されたデフォルトルートを受け入れることで設定される。
- 最小権限の原則
- 各アイデンティティ(人・アプリ・サービス)には、業務の遂行に必要な最小限の権限だけを与えるという設計原則。過剰な権限は誤操作や侵害時の被害範囲(ブラスト半径)を広げるため、IAM ロールやポリシー、権限境界を通じて継続的に絞り込む。
- 最小権限の原則とRBAC
- 利用者には業務上必要最小限の権限だけを付与するという最小権限の原則を、個々人にではなく職務・役割(ロール)単位で権限を割り当てて実装する方式がRBAC(ロールベースアクセス制御)。異動・退職時の権限見直しが容易になり、過剰な権限付与によるリスクを抑える。
- 最大許容停止時間(MTPD/MAO)
- 最大許容停止時間(MTPD、またはMAO:最大許容停止時間)は、事業が受容できるサービス停止の最大の長さで、これを超えると事業へ回復不能または深刻な損害が及ぶ限界を表す。復旧目標であるRTO(目標復旧時間)は、余裕を持たせるためMTPD/MAOより短く設定しなければならない。ITサービスマネージャは事業影響度分析からMTPD/MAOを見積もり、それを上限としてRTOと復旧戦略・投資を設計する判断を行う。
- 最短経路問題
- 重み付きグラフにおいて、始点から終点までの経路のうち辺の重みの総和が最小となる経路を求める問題。ダイクストラ法(非負重み)やベルマン-フォード法(負の重みも許容)などのアルゴリズムで解かれ、経路探索・カーナビ・ネットワークルーティングなど幅広く応用される。単純な幅優先探索は無重みグラフの最短経路しか求められない点が異なる。
- 最良証拠・補強証拠・間接証拠
- フォレンジック調査で証拠を評価する3分類。最良証拠は原本や直接の物的証拠で信頼性が最も高い。補強証拠は別の証拠を裏付ける追加の証拠。間接証拠(状況証拠)は事実を直接示さないが状況から推認させる証拠で、単独では立証力が弱く他の証拠と組み合わせて評価する。
- 災害対策(代替拠点・冗長化)
- 地震や火災などの災害で主拠点が被災してもITサービスを継続できるよう、地理的に離れた代替拠点(バックアップサイト)を確保し、サーバーや回線を冗長化(多重化)しておく対策。代替拠点は平常時から待機系を稼働させるか、被災時に構築するかで復旧速度とコストがトレードオフになる。RTO・RPOの目標値に応じて対策のレベルを選定する。
- 在庫管理
- 欠品による機会損失と過剰在庫による保管コストの両方を抑え、適正な在庫水準を保つための管理。在庫が一定量まで減った時点で発注する発注点方式や、発注1回あたりの費用と保管費用の合計が最小になる発注量を求める経済的発注量(EOQ)などの手法を用いる。
- 在庫評価
- 決算時に残っている在庫(棚卸資産)の金額を計算することです。仕入れ価格が変動する中でどの単価を使うかにより、先入先出法(古いものから払い出す)や移動平均法などの方法があり、選び方で利益額が変わります。
- 三点見積り(PERT)
- 楽観値(O)・最頻値(M)・悲観値(P)の3つの見積りから期待値を算出する技法。PERT加重平均は (O+4M+P)/6 で計算し、単一点見積りより不確実性を織り込める点で、レベル4の見積り精度向上に重要。
- 参照クエリ(Power Query)
- 既存クエリの出力結果を起点に新しいクエリを作る Power Query の機能。元クエリのステップは実体としてコピーされず、参照元が変わると参照クエリの結果も連動して変わる依存関係を持つ。共通の前処理を複数の下流クエリで再利用したいときに使う。
- 参照制約(参照整合性)
- 外部キーの値が、参照先テーブルの主キー(または候補キー)に実在する値でなければならないという制約。孤立した参照(親レコードのない子レコード)の発生を防ぎ、テーブル間の整合性を保証する。
- 参照列(Lookup)
- 別テーブルのレコードを参照する列。1 対多のリレーションシップを作り、関連データ(例:注文→取引先)をつなぐ。
- 産業財産権
- 特許権・実用新案権・意匠権・商標権の4つを指す総称。著作権と異なり、権利を得るには特許庁への出願・登録が必要。
- 残留リスク
- リスク対応(低減・回避・移転)を実施した後になお残るリスク。ゼロにはできないため、経営層が許容水準内にあるかを判断し、受容するかどうかを承認する対象となる。
- 使用レポート(usage report)
- 従量製品の消費量を組織/リポ別・傾向で把握するレポート。予算管理やチャージバック、コスト最適化の判断に使う。
- 使用状況メトリクス(GitHub usage metrics)
- Actions の実行時間・Packages/Codespaces のストレージ・ライセンス(シート)使用状況などの使用量を可視化し、課金・最適化に使うレポート。Enterprise/Organization の課金画面や使用状況レポートで確認する。
- 子プロセス
- あるプロセス(親)から起動された別のプロセス。シェルがコマンドを実行すると子プロセスが作られ、そこには環境変数だけが引き継がれる(export の必要性の理由)。
- 市民開発者
- 専門の開発者ではないが、業務知識を活かしてローコード/ノーコードでアプリやフローを作る現場の担当者。Power Platform が想定する主要ユーザー像。
- 指数バックオフ
- スロットリングやエラー発生時に、再試行までの待機時間を回数ごとに指数的に伸ばしていく再試行手法。多数のクライアントが同時に再試行してさらに負荷が集中する事態(サンダリングハード問題)を、ジッター(ランダムなずらし)を加えて緩和する。多くのクラウドSDKが既定で実装する。
- 試用環境(Trial)
- 期間限定(一定日数で自動削除)の評価用環境。プレミアム機能を一時的に試すのに使う。
- 資源平準化
- 特定の資源の割当てが上限を超えないように、アクティビティの開始・終了日を調整してスケジュールを見直す技法。制約を優先するためクリティカルパスが変化し、通常はプロジェクト終了日が延びる点が、単なる資源円滑化(フロート内調整のみ)との違いとして重要。
- 資産管理
- 組織が保有するハードウェア・ソフトウェアを台帳などで正確に把握・管理すること。何を保有しているか分からなければパッチ適用や脆弱性対応が漏れるため、セキュリティ対策の前提となる基礎的な活動。
- 事実性検証(ハルシネーション対策)
- 生成内容が根拠と一致するかを確かめる対策。RAG で根拠(出典)に基づかせるグラウンディング、出典との類似度・信頼度スコア、引用必須化、別モデルによる検証(LLM-as-a-judge)を組み合わせ、ハルシネーション(もっともらしい誤り)を抑える。
- 事前読み込み(pre-load)
- canvas アプリの起動時にデータを取得して体感性能を上げる手法。委任(データソース側処理)とは目的が異なる。
- 時間関数(age/now/current_date/current_timestamp/extract/to_char)
- 日時を扱う関数群。age は2つの日時の差、now/current_timestamp は現在時刻、current_date は現在日付、extract は日時値から年・月・日などの構成要素を数値(倍精度浮動小数点数)として取り出し、to_char は日時を指定書式の文字列へ変換する。
- 次元モデリング / スタースキーマ(ファクト・ディメンション・SCD)
- 分析/BI 向けのデータ設計。スタースキーマ=中央のファクトテーブル(数値メジャー+外部キー)の周囲にディメンションテーブル(日付・製品・顧客など分析の切り口)を放射状に配置(非正規化=BI で高速)。ファクトはまず粒度(グレイン=1 行が表す単位)を決める。ディメンションはサロゲートキー(システム生成の整数キー)を主キーにし業務キーと分離して結合/履歴を安定。SCD(Slowly Changing Dimension)=属性変化の扱いで、Type 1(上書き・履歴なし)/Type 2(行追加で履歴保持)/Type 3(前の値を列で保持)。日付ディメンション(連続日付)はタイムインテリジェンスの前提。スノーフレーク(さらに正規化)は結合増で BI 性能が落ちやすい。
- 次数と濃度
- 関係モデルにおいて、次数は表の属性(列)の数、濃度はタプル(行)の数を指す。次数はスキーマ設計時に決まり運用中は原則不変だが、濃度はデータの増減とともに変化する。
- 次世代ファイアウォール・ステートフルファイアウォール・Webコンテンツフィルタリング
- ステートフルファイアウォールは通信の状態(セッション)を追跡しそれに基づき許可・拒否を判定する。次世代ファイアウォール(NGFW)はこれにアプリケーション識別・侵入防止・ユーザー識別等の機能を統合する。Webコンテンツフィルタリングは閲覧先URLやカテゴリに基づき有害・業務外サイトへのアクセスを制限する。
- 自己結合
- 同一のテーブルを別名(エイリアス)を付けて2回以上参照し、自分自身と結合する操作。従業員テーブルの「上司」列から上司の氏名を引くなど、同じ表の中で階層関係や対応関係をたどるときに使う。
- 自然結合
- 同じ名前の列を等価条件として自動的に結合し、重複する列を1つにまとめる結合演算。結合条件を明示しなくてよい反面、意図しない列同士が一致してしまうと誤った結合になるため注意を要する。
- 自然言語処理(NLP)
- 言葉(テキスト/音声)を解析して意味・感情・意図を理解し、翻訳/要約する分野。
- 自動/手動フェイルオーバー(Cosmos DB)
- 単一書き込みリージョン構成で書き込みリージョンを移す操作。自動フェイルオーバーポリシーはリージョン障害時に優先順位に従い自動で移し、手動フェイルオーバーは計画的に意図して移す。
- 自動アタックディスラプション
- ランサムウェアや BEC など高信頼度で進行中の攻撃を検知した瞬間に、被害拡大を止める対応(侵害デバイスの隔離・侵害アカウントの無効化)を自動実行する Defender XDR の機能。XDR の横断シグナルで高確信度を得るため人手の承認を待たない。
- 自動クラウドフロー
- イベント(メール受信、項目作成など)を起点に自動で動くクラウドフロー。最も一般的な自動化の形。
- 自動スケール(スケーリングプラン)
- スケーリングプランに基づき、時間帯(ランプアップ/ピーク/ランプダウン/オフピーク)や負荷に応じてセッションホストを自動で起動/停止し、容量とコストを最適化する Azure Virtual Desktop の機能。接続時に 1 台を起動する Start VM on Connect とは別。
- 自動ダッシュボード(Automatic dashboard)
- 利用中の AWS サービスごとに、AWS があらかじめ選定した主要メトリクスを自動で表示するダッシュボード。カスタムダッシュボードを自分で作成しなくても、サービスの健全性を素早く俯瞰できる既定の画面として提供される。
- 自動チューニング(plan forcing)
- Azure SQL が推奨インデックスの自動作成や、退行時の FORCE LAST GOOD PLAN(直近の良いプランの強制)を自動適用する機能。
- 自動バックアップ / ポイントインタイムリカバリ(PITR)
- RDS のバックアップ。自動バックアップ=保持期間内(最大35日)の任意時点に復元できる(PITR、トランザクションログを利用)。手動スナップショット=明示取得し削除するまで残る(保持期間に縛られない)。復元は新インスタンス作成。
- 自動ページ更新(automatic page refresh)
- リアルタイム監視向けに、指定間隔やイベントでレポートページを自動更新する機能。DirectQuery など対応ストレージモードが前提。
- 自動応答(auto attendant)
- 着信を IVR(音声自動応答)メニューで出迎え、営業時間の判定やダイヤル入力に応じて部署・担当者・音声メール等へ振り分ける Teams 電話機能。resource account(リソース アカウント)を割り当てて電話番号を持たせ、営業時間外メッセージやコールフローの分岐を設定する。
- 自動化レベル(Defender for Endpoint)
- Defender for Endpoint のデバイスグループごとに、自動調査で見つかった修復アクション(ファイル隔離・プロセス停止等)を自動承認して実行するか、人手の承認を待って Action center に溜めるかを決める設定。フルオート寄りにするほど対応は速いが誤修復のリスクも上がる。
- 自動採番列
- レコード作成時に連番(接頭辞付きの一意な番号など)を自動で振る列。注文番号・チケット番号などに使う。
- 自動調査と応答(AIR)
- Defender XDR で、アラートをトリガーに自動で調査を実行し、影響エンティティを特定して修復アクション(隔離・プロセス停止等)を提案/実行する機能。修復の自動承認/承認待ちは自動化レベルで決まり、保留はアクションセンターで承認する。
- 自動登録(Intune)
- Windows デバイスが Microsoft Entra join(または hybrid join)と同時に自動で Intune へ登録される仕組み。MDM 機関の設定で自動登録を有効化しておけば、ユーザーがサインインするだけで手動の登録操作なしに管理下へ入る。会社所有デバイスの一括展開で前提となる設定。
- 自動評価パイプライン
- テストデータに対してグラウンド性・関連性・流暢さ・安全性などの指標を自動算出し、回帰を検知してモデル/プロンプトの変更可否を判断する仕組み。
- 自律型AP(Autonomous AP)
- WLCに依存せず、AP自身が設定・無線制御機能を単独で保持し完結して動作するアクセスポイント。小規模拠点や単体設置に向くが、台数が増えると1台ずつ個別設定・管理する必要がありローミングや集中監視も難しくなる。
- 式(${{ }})
- ${{ }} の中で評価される式。if: や値の埋め込みに使う。解析時(静的)と実行時(動的)の評価の違いがあり、シークレットを式やログに漏らさないことが重要。
- 式(エクスプレッション)
- フロー内でデータを加工・計算する関数式(日付整形・文字列結合・条件など)。動的コンテンツと組み合わせてアクションの入力を作る。
- 実効アクセス時間と参照の局所性
- 実効アクセス時間は階層記憶(キャッシュ+主記憶等)でのヒット率を加味した平均アクセス時間で、ヒット率×キャッシュ時間+ミス率×主記憶時間で計算する頻出計算問題。参照の局所性(時間的・空間的)はキャッシュが有効に働く根拠で、直近参照したデータや近傍アドレスが再び参照されやすい性質。
- 実行パイプラインのステージ
- プラグインを登録する段階。pre-validation(トランザクション外・最初・入力検証)、pre-operation(内・DB 書込前・値補正)、post-operation(内・DB 書込後・関連更新)。
- 実行プラン
- クエリの実行手順の図。スキャン対シーク・キールックアップ・非 SARGable 述語を見て、インデックスや書き換えで改善点を判断する。
- 実行計画
- オプティマイザが1つのSQL文をどの順序・どのアルゴリズム(結合方式・インデックス利用の有無など)で実行するかを決めた手順。DBMS が提供する解析コマンドで可視化でき、遅いクエリの原因(全表走査など)を診断する出発点になる。
- 実行履歴(run history)
- 同じワークフローの過去の実行一覧。いつ・どの変更から失敗し始めたかを特定し、原因切り分けに使う。
- 実費償還契約(コストプラス)
- 実際に発生したコストに、あらかじめ合意した報酬(定額または出来高に応じた割合)を上乗せして支払う契約類型。コスト超過のリスクは主に発注者側が負うため、要件が固まっていない探索的な開発に適する一方、発注者側のコスト管理・監視の負担が大きい点に注意。
- 主キー
- テーブルの各行を一意に識別する列。重複・NULL 不可。
- 主キーと外部キー(リレーショナルDB)
- 主キーは表の中で行を一意に識別する列(またはその組み合わせ)。外部キーは他の表の主キーを参照する列で、表と表の間の関連付け(リレーション)を実現する。
- 主記憶装置とキャッシュメモリ
- 主記憶装置(メインメモリ)はCPUが直接読み書きするプログラム・データの記憶領域。キャッシュメモリは主記憶より高速だが容量の小さいメモリで、CPUと主記憶の速度差を埋め処理を高速化する。
- 主成分分析(PCA・次元削減)
- 相関する多数の特徴量を、分散を最大化する少数の合成軸(主成分)へ圧縮する次元削減法。可視化・ノイズ低減・計算コスト削減に使う。教師なしで、解釈性は下がる。t-SNE/UMAP は可視化向けの非線形代替。
- 主要なハイパーパラメーター
- 学習を制御する設定値。学習率(ステップ幅)、バッチサイズ、エポック数、決定木の深さ、正則化の強さなどを調整して収束と汎化のバランスを取る。
- 手続き言語 PL/pgSQL(関数・プロシージャ)
- PostgreSQL に組み込まれた手続き型言語 PL/pgSQL は、制御構造(IF・ループなど)を使って関数やプロシージャを記述できる。関数は値を返し問い合わせ内で使え、プロシージャはトランザクション制御を含む一連の処理を CALL で実行する。
- 需要管理
- 需要管理は、サービスに対する需要を予測し、ピークを平準化(ピークシフト)することで資源の利用を最適化する活動である。差別化料金や利用時間帯の誘導などで需要のばらつきを抑え、過剰な設備投資を避けつつ能力不足を防ぐ。キャパシティ管理と密接に連携し、需要側の調整と供給側の増強を組み合わせる。ITサービスマネージャは需要パターンを分析し、供給能力を増やすか需要を平準化するかの費用対効果を比較して判断する。
- 収束(コンバージェンス)
- ネットワークトポロジの変化(リンク障害・経路追加など)後、全ルータが一致した経路情報を持つ状態に至るまでのプロセス、またはそれに要する時間を指す。収束が遅いと一時的にループやブラックホールが生じうるため、収束時間の短縮はルーティングプロトコル設計上の重要な評価指標である。
- 終了ステータス($?/exit)
- コマンドの成否を表す数値。$? で直前の終了ステータスを参照し、0 が成功・0以外が失敗。スクリプト自身の戻り値は exit N で指定する。&& や || による分岐の土台。
- 集計関数(Sum・CountRows ほか)
- テーブルの値を集計する関数。Sum は合計、Average は平均、CountRows は件数、Max/Min は最大/最小を返す。
- 集合とベン図
- 集合とは、ある条件を満たすものの集まりのこと。ベン図は、複数の集合の重なりや包含の関係を円で描いて視覚的に表す図で、和集合(どちらか)・積集合(両方)・補集合(含まれない部分)などの関係を直感的に理解できる。
- 集合演算(UNION/INTERSECT/EXCEPT)
- 複数の SELECT 結果を集合として組み合わせる演算。UNION は和集合(既定で重複除去、UNION ALL は重複を残す)、INTERSECT は積集合、EXCEPT は差集合を返す。
- 集合演算(和集合・積集合・補集合)
- 集合演算の基本3種。2つの集合の少なくとも一方に属する要素の集合が和集合(A∪B)、両方に共通して属する要素の集合が積集合(A∩B)、全体集合のうちある集合に属さない要素の集合が補集合(A^c)。ベン図で視覚的に表現され、条件の組み合わせを扱う設計・検索の基礎となる。
- 集中ログ(ログアーカイブアカウント)
- 組織のログ(CloudTrail・Config・VPC フローログ・アプリログ)を専用のログアーカイブアカウントの S3 へ集約し、改ざん防止(オブジェクトロック)と長期保管を行うベストプラクティス。Control Tower のランディングゾーンが標準で用意する。
- 集中処理と分散処理
- 集中処理は1台の中核システムに処理とデータを集約する方式で、管理・整合性維持が容易な反面、その1台が単一障害点となり性能上限にも縛られる。分散処理は複数ノードに処理を分けて可用性と拡張性を高めるが、通信・整合性・運用が複雑化する。システムアーキテクトは信頼性要件とコスト、運用体制を勘案して両者の配分を設計する。
- 集約 egress と送信専用 IGW
- インターネット送信を 1 つの VPC に集約し、TGW 経由で NAT ゲートウェイを共有してコストを下げる構成。IPv6 では送信専用インターネットゲートウェイ(Egress-Only IGW)でアウトバウンドのみ許可する。
- 集約シンク(aggregated sink)
- 組織やフォルダ配下のログを一括で収集し、BigQuery/Cloud Storage/Pub/Sub へエクスポートするログシンク。外部 SIEM への転送や長期保管に使う。単一プロジェクトのログシンクの上位概念。
- 集約とコンポジション(UMLの関連種別)
- UMLクラス図で全体と部分の関係を表す2種の関連。集約(白抜き菱形)は部分が全体から独立して存在できる緩い所有関係、コンポジション(黒塗り菱形)は全体が破棄されると部分も破棄される強い所有関係。多重度とあわせて出題される。
- 集約関数(count/sum/avg/max/min)
- 複数行を1つの値にまとめる関数群。count(count(*) は全行数)は件数、sum は合計、avg は平均、max/min は最大値・最小値を返す。GROUP BY と組み合わせてグループごとの集計に使う。
- 従量課金(metered)
- ユーザー単位(シート)に加えて消費量で課金される製品。Actions の分・ストレージ・Packages・Copilot・GHAS など。使用レポートで消費の多い組織/リポを把握する。
- 重大インシデント
- 事業への影響が甚大で緊急度も高いインシデント。通常の手順とは別に、専任の指揮体制と迅速な意思決定・情報連携を伴う専用手順で対応する。多くの組織が事前に定めた基準で重大インシデントを判定し、優先的に資源を投入して早期回復を図る。
- 重複検出
- 公開コードと一致する提案をブロック/抑制するセーフガード。ライセンス上の懸念を減らす。補助であり採用後のライセンス確認の責任は残る。
- 重要性(マテリアリティ)
- 監査における判断や結論に影響を与える事項の重大さの度合い。金額の大小といった量的な側面だけでなく、業務への影響度や法令遵守上の意味合いといった質的な側面も含む。監査人は重要性の判断に基づいて監査範囲や手続の深さを決定し、軽微な事項に監査資源を割きすぎないようにする。
- 出力の所有権とライセンス
- 採用したコードの所有権と責任は採用した利用者/組織にある。出力は公開コードと一致し得るためライセンスに配慮し、重複検出で対応する。
- 準仮想化(paravirtualization)
- ゲスト OS がハイパーバイザーの存在を認識し、専用のドライバ(virtio など)を通じて効率よくデバイスをやり取りする仮想化方式。実デバイスを完全にエミュレートする完全仮想化に比べ、I/O性能が高い。
- 準拠デバイス(compliant device)
- Intune で準拠と評価されたデバイス。Conditional Access の付与条件として「準拠デバイスを要求」に使う。
- 署名バージョン4(SigV4)
- AWS API リクエストにアクセスキーで署名する標準方式。リクエスト内容・日時・リージョン・サービスから署名を計算し、改ざん検知とリプレイ防止を行う。SDK/CLI が自動処理。署名付き URL もこの仕組みに基づく。
- 署名付き URL
- Cloud Storage のオブジェクトへ、期限付き・限定的なアクセスを公開せずに付与する URL。バケット全体を公開するのとは異なる。
- 助言型監査(コンサルティング)
- 監査対象の状況を評価したうえで、保証の表明よりも改善のための具体的な提言を行うことを主目的とする監査の形態。監査人は問題点の指摘にとどまらず、実務的な改善策を提示することが期待される。保証型監査に比べて監査人と被監査部門の協働的な色合いが強くなるため、独立性の確保に一層留意する必要がある。
- 承認(Power Automate)
- 承認依頼を担当者へ送り、承認/却下の結果に応じて後続処理を分岐させるクラウドフローの代表的ユースケース。Teams や Outlook から応答できる。
- 消費ベースの課金(従量課金)
- 確保した容量ではなく実際に使った分だけ支払う料金体系。初期投資が不要で無駄が少ない。
- 省電力
- 機器の消費電力を抑える工夫のこと。使っていない時間帯に自動でスリープ状態へ移行する、明るさを下げるなどが例。バッテリー駆動時間の延伸や電気代・環境負荷の低減につながり、バッテリーで動くIoT機器では特に重要になる。
- 証明書ベース認証(CBA)
- X.509 証明書でユーザーを認証するフィッシング耐性の高い方式。スマートカード等と組み合わせて高保証の認証を実現する。passkeys(FIDO2)と並ぶフィッシング耐性 MFA。
- 証明書失効(CRL / OCSP)
- 危殆化した証明書を期限前に無効化する仕組み。CRL=失効リストを配布。OCSP=オンラインで個別に失効状態を問い合わせ(OCSP ステープリングで効率化)。ACM Private CA(PCA)で自社 CA を運用する際に管理する。
- 詳細モニタリング
- EC2 メトリクスの収集間隔を標準の 5 分から 1 分へ上げるオプション(追加課金)。より細かい高解像度メトリクスは最小 1 秒粒度で送信できる。
- 障害回復
- ハードウェア障害やソフトウェア障害でデータベースに不整合が生じた際、ログ(更新前情報・更新後情報)やバックアップを用いて正常な状態に復旧させる処理。ロールバックによる未完了トランザクションの取消しと、ロールフォワードによる完了済みトランザクションの再現から成る。
- 障害切り分けの観点(サーバ停止・データ消失・OSリソース枯渇・プロセス状態分析)
- ps で postmaster とバックエンドプロセスの生死を確認し、df/du でディスク使用量、free でメモリを確認するのが障害の一次切り分けの定石。ディスクフルは特にWALの書き込み不能に直結し、最悪クラッシュに至るため最優先で除去すべき原因となる。データ消失が疑われる場合はPostgreSQLログでPGDATA/WALの破損有無を確認し、起動不能なら pg_resetwal による強制復旧や、直近のバックアップからのリストアを検討する。
- 冗長化
- 同じ役割の構成要素を複数用意し、1つが故障しても全体としてサービスを継続できるようにすること。HA構成の基本要素で、クラスタやレプリケーションと組み合わせて実現する。
- 冗長化(多数決方式)
- 同一の処理を行う系統を複数用意し、それぞれの出力を比較して多数決で正しい値を採用することで、単一系統の故障がシステム全体の誤動作に直結しないようにする信頼性設計手法。代表的な三重化多数決(TMR)では3系統中2系統が一致すればその値を採用し、1系統の故障を許容できる。
- 冗長性(LRS/ZRS/GRS/GZRS)
- データのコピー数と範囲で耐障害性を決める設定。LRS<ZRS<GRS<GZRS。GRS/GZRSは別リージョンへ複製。
- 情報システム戦略
- 経営戦略・事業戦略を実現するために、情報システムをどう整備・活用するかを定める上位方針。全体最適化計画やIT投資の優先順位付けの土台となり、個別システムの企画・開発はこの戦略に整合させる必要がある。
- 情報セキュリティ
- 情報を漏えい・改ざん・消失などの脅威から守り、安全に使える状態を保つ取り組みの総称です。情報セキュリティでは機密性(許可された人だけが使える)・完全性(内容が正しく保たれる)・可用性(必要なときに使える)の3要素(CIA)を守ることが基本で、ファイアウォールなどの技術的対策だけでなく、パスワード管理や教育といった運用面の対策も含みます。
- 情報セキュリティガバナンスとコーポレートガバナンス
- コーポレートガバナンス(企業統治)とは、株主・取締役会等が経営者の経営を監督し、経営の透明性・健全性を確保する仕組み。情報セキュリティガバナンスは、経営者が主導してセキュリティに関する方針決定・資源配分・監督を行う、コーポレートガバナンスの一部を構成する枠組みである。経営者自身がリーダーシップを発揮し、セキュリティを単なるIT部門の課題ではなく経営課題として位置づける点が特徴。
- 情報セキュリティの3要素(機密性・完全性・可用性)
- 情報セキュリティマネジメントの基本となる3つの要素。機密性は許可された者だけが情報にアクセスできること、完全性は情報が正確で改ざんされていないこと、可用性は必要なときに情報へアクセスできることを指す。
- 情報セキュリティポリシ(3階層)
- 組織の情報セキュリティに関する意思決定を文書化した体系。最上位の「基本方針」(経営層が定める理念・宣言)、それを具体化する「対策基準(スタンダード)」(守るべきルール)、実務手順を示す「実施手順(プロシージャ)」の3階層で構成される。上位ほど変更頻度が低く、下位ほど具体的で更新頻度が高い。
- 情報セキュリティ教育・訓練
- 規程やルールを整備するだけでなく、全従業員に対して定期的な集合研修・eラーニング・標的型攻撃メール訓練などを通じてセキュリティ意識と行動を定着させる継続的な取り組み。人的対策の実効性を左右する要であり、実施記録と理解度の測定が形骸化を防ぐポイント。
- 情報資産
- 組織にとって価値がありリスクアセスメントの対象となる情報およびそれを扱う仕組み全般。顧客データや設計情報などの「情報そのもの」に加え、それを保存・処理するサーバーやPCなどの「機器」、業務プロセスも含む。台帳を作成し重要度(機密性・完全性・可用性)を評価するのが管理の出発点。
- 情報伝達経路数(n(n-1)/2)
- プロジェクトの関係者数 n に対して n(n-1)/2 で算出される、一対一の潜在的なコミュニケーション経路の総数。人数が増えるほど経路数が急増しコミュニケーションの複雑さが増すことを定量的に示し、体制設計やコミュニケーション計画の必要性を判断する根拠として重要。
- 情報流通プラットフォーム対処法
- SNS等の大規模プラットフォーム事業者に対し、権利侵害情報(誹謗中傷等)の削除申出への対応の迅速化・運用状況の公表などを義務付ける法律。従来のプロバイダ責任制限法を改正・改称したもの(Ver.4.1適用)。旧名称「プロバイダ責任制限法」は現行シラバスでは使われない点に注意。
- 情報量(エントロピー)
- ある事象の起こりにくさを定量化した尺度。発生確率pの事象の情報量は-log2 pビットで表され、確率が低い(珍しい)事象ほど情報量が大きい。平均情報量(エントロピー)は各事象の情報量を発生確率で重み付けした期待値で、情報源全体の不確実性の大きさを示す。
- 条件付きアクセス
- 場所・デバイス・リスクなどの条件に応じてアクセスを許可・追加要求する(ゼロトラストの実装)。
- 条件付き書式(Power BI)
- 値に応じて背景色/フォント色/データバー/アイコンを変えて注目点を強調する書式。テーマ(配色の一括適用)とは別物。
- 状態遷移図(ステートマシン図)
- 1つのオブジェクトやシステムが取りうる状態と、イベントによって状態から状態へ移る遷移を表す図。遷移にはトリガとなるイベント、成立条件(ガード条件)、実行される動作を対応づけられ、状態依存の振る舞いを漏れなく定義できる。取りうる状態が有限で明確な制御対象(組込み制御や注文の進行など)のモデル化に適する。
- 状態遷移表
- システムが取りうる状態と、各状態においてイベントが発生した場合の遷移先状態・実行アクションを行列形式で網羅的に整理した表。状態遷移図に比べ、全ての状態とイベントの組合せを漏れなく記述でき、未定義の組合せ(想定外のイベント)を発見しやすいため、組込み制御ソフトウェアの仕様検証に適する。
- 畳み込み層とプーリング層
- CNN(畳み込みニューラルネットワーク)を構成する代表的な層。畳み込み層はフィルタ(カーネル)を画像上で走査し、局所的な特徴(エッジなど)を検出した特徴マップを生成する。プーリング層は特徴マップを一定領域ごとに集約(最大値を取るMaxプーリングなど)してサイズを縮小し、位置ずれへの頑健性と計算量削減をもたらす。
- 職業倫理と職業的懐疑心
- 職業倫理は、誠実性・客観性・専門的能力・守秘義務など監査人が遵守すべき行動規範である。職業的懐疑心は、被監査部門からの説明や提示された証拠を鵜呑みにせず、矛盾や不備がないかを常に批判的な視点で吟味する監査人の姿勢を指す。両者は監査結論の信頼性を支える土台であり、独立性が保たれていても懐疑心を欠けば重要な不備を見逃しかねない。
- 職務分掌
- 強い権限を 1 人に集中させず、申請者と承認者を分けるなどのチェックを効かせる設計原則。単独での不正・誤操作を防ぐ。最小権限と併用する。
- 職務分掌(内部統制における)
- 不正や誤りを防ぐため、承認・実行・記録・保管といった一連の業務を1人に集中させず複数人で分担させる内部統制の基本原則。
- 信頼された起動(Trusted Launch)
- VM のブートレベルの保護。セキュアブート(署名されたブートローダーのみ起動)・仮想 TPM(vTPM)・整合性監視を提供し、ルートキットやブートレベルのマルウェアを防ぐ。VM の security type として構成する。保存時のディスク暗号化とは別レイヤー。
- 信頼ポリシー
- IAM ロールに付随する特殊なリソースポリシーで、「誰がこのロールを引き受けられるか(sts:AssumeRole を実行できるか)」を定義する。ロール自体のアクセス許可を決めるアイデンティティベースポリシーとは別物で、両方が揃って初めてロールの引き受けが成立する。
- 信頼ルール(trust rules)
- どの外部組織(ドメイン)とのファイル共有を許可/制限するかを定め、外部共有を統制する仕組み。相手ドメインベースで、内容ベースの DLP とは軸が異なる。
- 信頼区間
- 同じ手続きで区間推定を繰り返した場合に、そのうち一定割合(例:95%)が真の値を含むように構成された範囲(例:95% 信頼区間)。単一の区間について「真の値を含む確率が95%」という意味ではなく、手続き全体の性質を表す。点推定だけでなく不確実性の幅を併記することで、サンプルサイズや変動性を踏まえた妥当な解釈ができる。
- 信頼性(Reliability)
- 障害や災害から回復し、耐える能力。HAが「落とさない」なら信頼性は「倒れても立ち直る」。
- 深層学習
- 多層のニューラルネットワークを用いる手法。画像・音声・言語など複雑なデータに強い。
- 深層学習アーキテクチャ(CNN/RNN/Transformer)
- データの構造で選ぶ。CNN=畳み込み+プーリングで画像/空間データの局所特徴(画像分類・物体検出)。RNN/LSTM=ステップ間の記憶で系列/時系列(順序が重要、ただし並列化困難・長距離に弱い)。Transformer=自己注意で長距離文脈を並列に捉え言語/長系列に強い(BERT/GPT、計算量は系列長の二乗)。
- 真正性
- 情報セキュリティの拡張要素の一つで、利用者・情報・処理が主張どおりの本人・本物であることを確保する性質。デジタル署名や多要素認証によって、なりすましや偽装がないことを裏付ける。機密性・完全性・可用性のCIAトライアドを補う概念として応用情報の午前で問われる。
- 診断とログ(App Service)
- アプリ/Web サーバー/詳細エラーのログ収集とログストリームでのリアルタイム確認。App Insights と連携して監視する。
- 診断設定
- 各リソースのログ・メトリックの送付先(Log Analytics ワークスペース/ストレージアカウント=長期保管/Event Hub=外部 SIEM 連携)を指定する構成。診断設定をしない限りリソースログは既定では集約されない点に注意(アクティビティログはサブスクリプション単位で自動記録される)。データ収集ルール(DCR)で収集対象や変換を細かく制御できる。
- 垂直スケーリング(スケールアップ)
- 1台のインスタンスのスペック(CPU・メモリ等)を増強するスケーリング方式。アプリの構成変更が少なく手軽だが、インスタンスタイプの上限があり、単一障害点になりやすく、変更時に停止を伴うことが多い。水平スケーリングと対比される選択肢。
- 垂直分散と水平分散
- 垂直分散(機能分散)は層や機能ごとに別マシンへ役割を分けて配置する方式で、プレゼンテーション用とデータベース用を分けるなど機能単位の独立性を高める。水平分散(負荷分散)は同一機能を担うマシンを複数複製し、負荷分散装置で処理要求を振り分けて処理能力と可用性を高める。両者を組み合わせて拡張性を設計するのがアーキテクトの典型的判断である。
- 推薦システム(協調フィルタリング)
- ユーザーとアイテムの相互作用から好みを予測する。協調フィルタリングは似たユーザー/アイテムの行動を使い、SageMaker では Factorization Machines が代表的。
- 推論の種類(リアルタイム/バッチ)
- リアルタイム推論は低遅延で 1 件ずつ応答、バッチ推論は大量データをまとめて非同期処理する。レイテンシ要件とコストで選ぶ。
- 推論パイプライン(マルチコンテナ)
- 前処理→推論→後処理を複数コンテナの連鎖として 1 つのエンドポイントにまとめる SageMaker の構成。学習時と同じ変換を推論時に再利用できる。
- 推論パラメータ(温度・top-p・コンテキストウィンドウ)
- 温度/top-pは出力の多様性(低い=一貫的/高い=創造的)、コンテキストウィンドウは一度に扱える入力+出力トークンの上限。
- 水平スケーリング(スケールアウト)
- インスタンスの台数を増やして負荷を分散するスケーリング方式。ステートレス設計とロードバランサ・Auto Scalingが前提になり、1台の故障がシステム全体に影響しにくいため耐障害性も高まる。クラウドネイティブな設計では基本の方向性とされる。
- 数値列(整数・10進数)
- 数を格納する列。整数・10進数・浮動小数点などの型があり、計算や集計に使える。
- 制御構文(if/case/for/while)
- スクリプトの分岐と反復。if…fi は条件分岐([ ] は test)、case…esac は値をパターンで多分岐、for/while…done は反復。閉じ語(fi/esac/done)を取り違えないのが要点。
- 性能の指標(IOPS/スループット/帯域幅/レイテンシー)
- 性能を測る基本語彙。IOPS=1 秒あたりの I/O 回数(小さなランダムアクセスの指標、EBS io2 等)。スループット=単位時間のデータ量(MB/s、大きな連続転送)。帯域幅=回線容量。レイテンシー=1 操作の遅延。ワークロードに合う指標で設計・監視する。
- 整合性チェック(DBCC CHECKDB)
- データベースの論理的・物理的な破損を検査するコマンド。定期実行で破損を早期検出し、バックアップと併せてデータ保全を担保する。
- 整合性レベル(Cosmos DB)
- 読み取りの一貫性と性能/可用性のトレードオフを選ぶ 5 段階:強固→有界整合性制約→セッション(既定)→整合性のあるプレフィックス→最終的。
- 整列アルゴリズム
- データを大きさ順(昇順・降順)などの決まった順序に並べ替える手順のこと。隣同士を比べて交換を繰り返すバブルソートなどがあり、あらかじめ整列しておくことで二分探索などの効率的な処理が可能になる。
- 整列アルゴリズム(バブルソート・クイックソート・マージソート)
- データを一定の順序に並べ替えるアルゴリズム群。バブルソートは隣接要素の交換を繰り返す単純だがO(n^2)の方式、クイックソートは基準値で分割する平均O(n log n)の高速な方式、マージソートは分割統治で安定的にO(n log n)を保つ方式。
- 整列の安定性(安定ソート)
- 整列前に等しいキーを持つ要素同士の相対順序が、整列後も保たれる性質。マージソートは安定ソートだが、クイックソートは実装によっては不安定になる。
- 正引き
- ドメイン名からIPアドレスを求めるDNS解決。IPv4はAレコード、IPv6はAAAAレコードを用いる。IPアドレスからドメイン名を求める逆引き(PTRレコードを使用)と対をなす概念で、通常のWebアクセスやメール送信時の名前解決は正引きが用いられる。
- 正規化
- 重複を減らし整合性を保つようにテーブルを分割・設計すること。更新時異常を防ぐ。
- 正規化とデータベース設計
- 冗長性や更新時異常(update anomaly)を排除するため表を段階的に分解する設計手法。第一正規形(1NF)は各列の値が原子値(atomic value・単一値)であることを要求する。第二正規形(2NF)は1NFを満たした上で部分関数従属(主キーの一部にのみ従属する列)を排除し、第三正規形(3NF)はさらに推移的関数従属(非キー列を介した間接的な従属)を排除する段階。データベース設計はこの正規化を含めた表構造の決定プロセス全体を指す。
- 正規化の段階(第1正規形〜第3正規形)
- リレーショナルデータベースの設計でデータの冗長性・更新異常を減らす段階的な手法。第1正規形は繰り返し項目を排除、第2正規形は主キーの一部にのみ従属する項目を分離、第3正規形は主キー以外の項目に従属する項目(推移的関数従属)を分離する。
- 正規表現
- 文字列のパターンを記述する言語。^ 行頭・$ 行末・. 任意1文字・[abc] 集合・* 直前要素の0回以上。基本正規表現(BRE)と拡張正規表現(ERE:+ ? | ( ))があり、シェルのワイルドカードの * とは意味が異なる(任意文字列は .* と書く)。文法詳細は regex(7)。
- 正規表現とオートマトン
- 正規表現は文字列のパターンを記号で表す表記法で、その処理は有限オートマトン(状態遷移)として実装できる。文字列探索やパターンマッチングの理論的基盤。
- 正規分布
- 平均値を中心に左右対称な釣鐘型をなす連続確率分布で、平均μと標準偏差σの2つのパラメータで特徴づけられる。自然現象や測定誤差など多くの現象がこの分布に従うとされ、平均±1σの範囲に約68%、±2σの範囲に約95%のデータが含まれる性質が統計的推定や品質管理で利用される。
- 生成 AI
- 学習データをもとに文章・画像・コードなど新しいコンテンツを生成するAI。分類/回帰とは別用途。
- 生成 AI アプリのセキュリティ(Bedrock Guardrails・OWASP LLM)
- SCS-C03 で追加。LLM アプリの脅威は OWASP Top 10 for LLM(プロンプトインジェクション・機微情報漏えい・安全でない出力処理・過剰なエージェンシー等)を指針に対策する。Amazon Bedrock Guardrails がコンテンツフィルタ・禁止トピック・PII マスキング・コンテキストの根拠付け・プロンプト攻撃フィルタを入出力に適用。アクセスは IAM で InvokeModel を最小権限に限定、通信は VPC エンドポイント、暗号化は KMS、監査は CloudTrail とモデル呼び出しログ。Bedrock は顧客データを基盤モデルの再学習に使わない。
- 生成 AI のリスク(毒性/プロンプトインジェクション)
- 毒性(有害表現)・偏り・ハルシネーション・知的財産の侵害・プロンプトインジェクション・データ漏えいなどのリスク。Guardrails やフィルタで緩和する。
- 生成 AI の監視(固有メトリクス / golden dataset)
- 生成 AI 固有の品質監視。正確性・グラウンディング率・有害性・拒否率・レイテンシ/コストを追い、golden dataset(基準となる入力と期待出力の集合)に対する回帰で品質劣化を検知する。CloudWatch・Bedrock ログ・人手評価を併用する。
- 生成 AI の監視とトレース
- モデルの性能・リソース消費を診断設定で監視し、トレースで各実行を記録、フィードバックを収集して継続改善する。
- 生成 AI の継続的監視(ドリフト/バイアス)
- 本番の生成品質を継続監視し、データドリフト・バイアスドリフト・ガードレール違反・コスト/レイテンシ異常を自動検知して是正につなげる運用。CloudWatch メトリクス・Bedrock のログ・モデル評価・人手レビューを組み合わせる。
- 生成 AI の評価指標(BLEU/ROUGE)
- 生成テキストの品質を測る指標。BLEU は翻訳の一致度、ROUGE は要約の再現度、BERTScore は意味的類似度を測る。最終的には人手評価も併用する。
- 生成 AI の品質メトリクスと評価
- 生成 AI は出力が一意でないため評価が運用の要。AI 品質メトリクス=根拠性(提供根拠に基づくか=ハルシネーションの逆)/関連性(質問に答えるか)/一貫性(論理性)/流暢性(自然さ)。加えてリスク・安全性の評価(有害コンテンツ/脱獄耐性)を、組み込み+カスタムメトリクスの自動評価ワークフローとして品質ゲート化する。
- 生成 AI の本番監視(ドリフト/品質/安全性)
- 本番のモデル出力を継続監視し、品質低下・グラウンド性の劣化・有害出力・データ/プロンプトの変化を検知してアラートと再評価につなげる。
- 生成AI(ジェネレーティブAI)
- 文章・画像・音声・プログラムコードなど新たなコンテンツを生成できるAI。業務効率化に有用な一方、誤った情報をもっともらしく生成するハルシネーションや著作権侵害のリスクにも注意が必要。
- 生体認証
- 指紋・顔・虹彩・静脈などの身体的特徴(生体情報)を用いて本人確認を行う認証方式。多要素認証の「生体情報」要素として使われる。精度の指標に、本人を誤って拒否する割合の本人拒否率(FRR)と、他人を誤って受け入れる割合の他人受入率(FAR)があり、両者はトレードオフの関係にある。
- 精神的独立性と外観的独立性
- 精神的独立性は、監査人が先入観や利害にとらわれず客観的な姿勢で判断を行う内面的な独立性を指す。外観的独立性は、第三者から見て監査人が被監査対象と特別な利害関係を持たないと認識される外形的な独立性を指す。自らが関与した業務や設計したシステムを自分で監査することは、実質的に公正でも外観的独立性を損なうため避けるべきとされる。
- 製造物責任法(PL法)
- 製造物の欠陥により生命・身体・財産に被害が生じた場合、製造業者等が過失の有無にかかわらず損害賠償責任を負う(無過失責任)ことを定めた法律。被害者は製造業者側の過失を立証する必要がなく、製品に欠陥があったこと・損害が発生したこと・両者の因果関係を立証すれば足りるため、製造業者側の責任が問われやすい枠組みになっている。ソフトウェア単体は原則対象外だが、組み込まれたハードウェア製品の欠陥には適用され得る。
- 製品とサブスクリプション(APIM)
- API を「製品」としてまとめ、利用者はサブスクリプション(キー)で利用する仕組み。公開範囲や利用条件を製品単位で管理する。
- 製品ライフサイクル(PLC)
- 製品が市場に投入されてから撤退するまでを、導入期・成長期・成熟期・衰退期の4段階で捉えるフレームワーク。ストラテジストは各段階で売上・利益・競合状況が異なることを踏まえ、導入期は認知獲得への投資、成長期はシェア拡大、成熟期は差別化や関連製品への展開、衰退期は撤退や刈り取りといった、段階に応じた戦略判断を行う。
- 請求アラーム
- CloudWatch の EstimatedCharges メトリクスにしきい値を設定し、想定外の課金を早期に検知する仕組み。このメトリクス自体は us-east-1(バージニア北部)でのみ記録されるため、請求アラームも us-east-1 で作成する必要がある。
- 脆弱性管理
- 組織のシステムに存在する脆弱性を継続的に特定・評価し、深刻度に応じて優先順位をつけて修正・緩和していく一連のプロセス。スキャンによる特定、CVSS等での評価、パッチ適用やハードニングによる対応、再確認までを繰り返す。
- 脆弱性診断
- Webアプリケーションやネットワーク機器・サーバーに既知の脆弱性が存在しないかをツールや専門家が検査するサービス・作業。ペネトレーションテストが「実際に侵入できるか」を試すのに対し、脆弱性診断は網羅的に既知の弱点をリストアップする点で目的が異なる。
- 責任ある AI
- AIを安全・公正・透明に使う指針。Microsoftの6原則=公平性/信頼性と安全性/プライバシーとセキュリティ/包括性/透明性/説明責任。
- 責任ある AI の柱
- 公平性・説明可能性・透明性・堅牢性・プライバシー・安全性・ガバナンスといった観点で AI を設計・運用する。バイアスや有害な出力を抑える。
- 責任追跡性
- 情報セキュリティの拡張要素の一つで、いつ誰がどの操作を行ったかを後から追跡・特定できる性質。ログの記録と保全、監査証跡の管理によって実現され、不正アクセスや誤操作の原因究明・説明責任の担保に用いられる。
- 責任分担マトリクス(RAM/RACI)
- 作業とチームメンバーを対応づけ、各役割を実行責任(R)・説明責任(A)・相談対応(C)・情報共有(I)に分類する表。1つの作業に対しA(説明責任)は必ず1人に定めるのが原則で、責任の重複や空白を防ぐことがプロジェクト統制上重要。
- 接続プーリング
- データベースへの接続をあらかじめ確立してプールに保持し、リクエストのたびに新規接続を張るオーバーヘッドと接続数の枯渇を防ぐ仕組み。Amazon RDS Proxyが代表例で、Lambdaのようなサーバーレス/高並行なアプリで特に効果が大きい。
- 接続モード(gateway / direct)
- Cosmos DB SDK の 2 つの接続方式。ゲートウェイは HTTPS(443)経由でファイアウォール越えが容易だが遅延やや大。ダイレクトは TCP でレプリカに直接つなぎ低遅延・高スループットで本番に推奨。CosmosClient はシングルトンで再利用する。
- 接続モニター(Connection Monitor)
- エンドポイント間の到達性・遅延・パケットロスを継続的に監視する Network Watcher の機能。経路の変化や障害を検知する。
- 接続参照(Connection reference)
- フローが使うコネクタ接続を、ソリューションで移送可能にする抽象化。環境ごとに実際の接続を割り当て直せる。
- 絶対パスと相対パス
- 絶対パスは / から始まる完全な位置(/etc/hosts)、相対パスは現在地からの位置(./script.sh、../dir)。現在地は pwd で確認する。
- 先行関係(FS/SS/FF/SF)
- アクティビティ間の順序制約の型。終了-開始(FS)・開始-開始(SS)・終了-終了(FF)・開始-終了(SF、まれ)の4種があり、最も一般的なのはFS。スケジュールネットワーク図の正しい依存関係を表現し、クリティカルパスの算出根拠になる点で重要。
- 専有インスタンス(Dedicated Instance)
- 他の AWS アカウントのテナントとハードウェアを共有しない EC2 インスタンス配置。物理的には分離されるが、専有ホストと異なりホストの可視性(ソケット/コアID)は持たない。コンプライアンス要件で物理分離が必要だがライセンス上の可視性までは不要な場合に選ぶ。
- 専有ホスト(Dedicated Host)
- 物理サーバー1台を丸ごと占有する EC2 配置オプション。ソケット・コア・ホストIDが可視化され、既存のソケット/コア単位のソフトウェアライセンス(BYOL)を持ち込みたい場合に使う。専有インスタンスより高価だが、同一ホスト上のインスタンス配置を制御できる。
- 戦略マップ(BSC)
- BSC(バランススコアカード)の財務・顧客・内部業務プロセス・学習と成長という4つの視点間の因果関係を1枚の図に可視化したもの。「学習と成長」の向上が「内部プロセス」の改善につながり、それが「顧客」満足を高め、最終的に「財務」成果に結び付くという戦略ストーリーを示す。ストラテジストは戦略マップによって、抽象的な経営戦略を現場のKPIまで一貫した因果の連鎖として説明し、組織内の合意形成に用いる。
- 線形回帰
- 連続値のターゲットを、特徴量の重み付き線形結合として予測する基本的な教師あり学習モデル。解釈しやすく、回帰問題のベースラインとしてまず試されることが多い。
- 線形計画法
- 複数の制約条件(一次不等式)の下で、目的関数(利益や費用などの一次式)を最大化または最小化する解を求める数理計画法。生産計画や資源配分の最適化問題に用いられ、制約領域の頂点(実行可能領域の端点)のいずれかで最適解が得られる性質を利用して解く。
- 線形探索(リニアサーチ)
- 配列やリストの先頭から順に1つずつ要素を調べて目的の値を探す探索法。整列されていないデータにも使えるが、計算量はO(n)で二分探索より遅い。
- 選択肢列(choice)
- 決められた候補から選ばせる列の型(旧称オプションセット)。表記ゆれを防ぎ、データの一貫性を保つ。単一選択と複数選択がある。
- 全二重
- 送信と受信を同時に独立して行える通信方式で、スイッチのポート同士を専用線接続する現代のイーサネットで標準的に用いられる。送受信が同時に行えるためCSMA/CDによる衝突検知・回避が不要になり、コリジョンドメインが発生しない。対義語の半二重は送受信を交互にしか行えない方式で、ハブ接続や無線LANの一部モードで見られる。
- 疎結合(デカップリング)
- コンポーネント間を直接呼び出しでなくキュー(SQS)や通知(SNS)・イベント(EventBridge)で分離する設計。片方の障害や負荷変動が連鎖せず、独立してスケール・更新できる。バッファリングでスパイクも吸収。
- 組合せ回路/順序回路
- 組合せ回路は出力が現在の入力のみで決まる回路(AND/OR/NOT等の組合せ)、順序回路はフリップフロップ等の記憶素子を持ち、現在の入力に加え過去の状態(内部状態)にも出力が依存する回路。組込みのタイミング設計や状態遷移設計の基礎となる区別で、後者はクロックに同期した動作解析が必要。
- 組込みシステム
- 家電・自動車・産業機器などの製品に組み込まれ、特定の機能を実現するために専用化されたコンピュータシステム。汎用コンピュータと異なり、限られたメモリ・処理能力・消費電力といった制約の中で、リアルタイム性や高い信頼性を求められることが多い。マイコンを中核とし、センサやアクチュエータと連携して機器を制御する。
- 組織ポリシー(Organization Policy)
- リソース階層に沿って制約を継承・強制し、組織全体に一貫したルール(例: 特定リージョン以外の作成禁止)を適用する仕組み。IAM の許可とは別。
- 組織ロール(owner/member/security manager)
- 組織全体を統制するオーナー、一般のメンバー、特定の管理権限を切り出した security manager など。オーナーは強力なため付与は最小限に。
- 組織単位(OU)
- AWS Organizations 内でアカウントを階層的にグループ化する単位。OU 単位で SCP を適用し、環境(本番/開発)や部門ごとにガードレールを分けて統制する。
- 双方向フォワーディング検出(BFD)
- 隣接ルーター間の障害を高速に検出するプロトコル。ExpressRoute で有効化すると BGP の収束を速め、フェイルオーバーを早める。
- 早期終了ポリシー(Bandit/中央値停止)
- 見込みの薄い試行を打ち切ってコストを抑えるスイープの設定。Bandit(スラックファクター)・中央値停止・切り捨て選択などがある。
- 相関
- 2 つの変数がどれだけ連動して動くかを示す統計指標(相関係数)。値が強くても、一方が他方の原因であるとは限らない(相関≠因果)ため、探索的データ分析での解釈には注意が必要。
- 相関関係と因果関係(iパス基礎理論)
- 相関とは2つの事象の間に何らかの関係性が見られること。因果とは一方が原因となり他方が結果として生じる関係のこと。相関があっても必ずしも因果関係があるとは限らない点に注意が必要(見せかけの相関)。
- 相見積り
- 同一の調達条件を複数の供給者に提示し、それぞれから見積書を取得して価格・納期・品質を比較検討する調達手法。特定業者との癒着や不当に高い価格での契約を防ぎ、調達の透明性・妥当性を高める目的で用いられる。
- 相対参照と絶対参照(表計算)
- 表計算ソフトで数式が参照するセルの指定方法。相対参照は数式をコピーすると参照先が位置に応じてずれる方式で、行ごとに違うセルを計算したいときに便利。絶対参照は「$」を付けて参照先を固定し、消費税率のように全ての行で同じセルを参照し続けたいときに使う。行か列の一方だけを$で固定する複合参照(例:$A1、A$1)もある。
- 総保有コスト(TCO)
- 機器の購入費だけでなく、電力・冷却・保守・運用人件費・更新まで含めた総コスト。オンプレミスとクラウドの正しい比較に用いる。
- 送信ドメイン認証(SPF/DKIM/DMARC)
- 送信ドメイン認証の 3 要素。SPF はそのドメインからの送信を許可する IP を列挙し、DKIM は電子署名でメール本文の改ざんの無さと送信元を証明し、DMARC は SPF/DKIM の検証結果に基づく処理方針(隔離/拒否)と結果通知先を宣言する。なりすまし・フィッシング対策として TXT レコードで設定し、Google Workspace でも受信側の迷惑メール判定に強く影響する。
- 送信規則と SNAT(Load Balancer)
- バックエンドプールの VM がインターネットへ送信する通信の送信元アドレスを、Load Balancer のフロントエンド IP に変換(SNAT)する仕組み。パブリック IP を持たない VM のアウトバウンド接続を可能にし、送信規則でポート割り当て(SNAT ポートの枯渇に注意)を制御する。
- 増分バックアップ
- 直前のバックアップ(完全または増分)以降に変更されたデータだけを複製するバックアップ方式。各回のバックアップは最小で済むが、リストアには完全バックアップ以降の全増分を順番に適用する必要がある。
- 増分更新(セマンティックモデル)
- モデル更新で、変更のあった最近の区画だけを取り込み、過去分は再取得しない仕組み。更新時間とリソースを大幅に削減する。
- 損益計算書
- 一定期間の収益と費用を対応させ、企業の経営成績(利益または損失)を示す財務諸表。売上高から売上原価を引いて売上総利益、販管費を引いて営業利益、営業外損益を加減して経常利益、というように段階的に利益を算出する。P/Lとも呼ばれる。
- 損益分岐点
- 売上高と総費用(固定費+変動費)がちょうど一致し、利益も損失も出ない売上高(または販売数量)。損益分岐点比率が低いほど、少ない売上でも黒字化しやすい体質と言える。
- 損益分岐点売上高
- 利益がちょうどゼロになる売上高。損益分岐点売上高=固定費÷(1-変動費率)(変動費率=変動費÷売上高)で求める。実際の売上高がこれを上回れば黒字、下回れば赤字となり、経営の安全余裕度(安全余裕率)を測る指標としても用いられる。
- 多重化
- 複数の信号やデータストリームを1つの伝送路上で同時に送るための技術で、周波数を分割するFDM、時間を分割するTDM、光の波長を分割するWDM(光ファイバ)、符号で分離するCDMAなどの方式がある。1本の物理回線を効率的に共用できる反面、多重分離(デマルチプレクス)を受信側で正しく行う必要がある。
- 多重割込み(ネスト割込み)
- 割込み処理の実行中に、より優先度の高い別の割込みが発生した場合にそれを受け付け、現在の処理を中断して優先度の高い割込みを先に処理する仕組み。緊急性の高いイベントへの応答性を確保できる一方、スタック消費の増大や、割込み処理中のクリティカルセクション設計を誤ると不整合を招くため注意が要る。
- 多層防御
- 防御を何層にも重ね、1つ破られても次の層で守る考え方(ID・ネットワーク・データなど)。
- 多層防御(入口・内部・出口対策)
- 侵入を100%防ぐことは不可能という前提に立ち、入口対策(FW/WAFで侵入自体を防ぐ)・内部対策(権限管理やEDRで侵入後の被害を局所化する)・出口対策(DLPやプロキシで外部への情報流出を止める)を多段に組み合わせる考え方。単一の対策への過信を避ける。
- 多値従属
- 1つの属性(または属性集合)の値が決まると、他の属性の値の集合が(別の属性とは独立に)一意に定まるという関係。1つの表に複数の独立した多値従属が同居すると冗長な組合せが生じ、第4正規形への分解で解消する。
- 多要素認証(MFA)
- パスワードに加え第二の要素で本人確認を強化する仕組み。
- 多要素認証(知識・所持・生体)
- 知識情報(パスワード等)・所持情報(スマートフォンやICカード等)・生体情報(指紋や顔等)のうち、異なる2種類以上を組み合わせて本人確認を行う認証方式。1つの要素が漏えいしても不正ログインされにくくなる。
- 楕円曲線暗号(ECC)
- 楕円曲線上の離散対数問題の困難性を安全性の根拠とする公開鍵暗号。RSAより短い鍵長で同等の強度を得られるため、処理負荷や鍵サイズが制約される環境で利用される。署名方式はECDSA、鍵交換はECDHEとして使われる。
- 対応計画(response plan)
- 検知した脆弱性/アラートを「誰が・どの優先度で・いつまでに」対応するかを定めた計画。SLA・役割・記録を含め、放置を防いで確実に修復する。
- 対象群(知識エリア)
- JIS Q 21500が定める10のマネジメント領域(統合・ステークホルダ・スコープ・資源・時間・コスト・リスク・品質・調達・コミュニケーション)の総称。各対象群が複数のプロセス群にまたがって活動を持つ点を理解することが、PM標準の全体構造を把握する上で重要。
- 耐タンパ性
- ICカードやセキュリティチップ(TPM等)が、内部の秘密情報(鍵など)を物理的な分解・観測・改変の試みから保護する能力。サイドチャネル攻撃や物理的攻撃に対し、情報の読み出しや不正操作を困難にする実装上の性質。
- 耐久性と可用性(ナイン)
- 耐久性=データを失わない確率(S3 は 99.999999999%=イレブンナイン=ほぼ消失しない)。可用性=サービスにアクセスできる確率(例 99.99%=年約52分のダウン)。両者は別概念。SLA は可用性で示されることが多い。
- 待ち行列理論(M/M/1)
- 客の到着や窓口でのサービスをランダムな事象としてモデル化し、待ち時間や行列長を確率的に分析する理論。M/M/1モデルでは到着率λ・サービス率μに対して利用率ρ=λ/μを求め、ρが1に近づくほど平均待ち時間・平均待ち行列長が急激に増大する。窓口数やサービス能力の設計に用いられる。
- 待機統計
- セッションが何を待っているか(I/O・ロック・CPU 等)を示す指標。ボトルネックの種類を切り分ける出発点になる。
- 貸借対照表
- 決算日時点における企業の資産・負債・純資産の状態を示す財務諸表。左側(借方)に資産、右側(貸方)に負債と純資産を記載し、資産=負債+純資産の関係が常に成立する。企業の財政状態(支払能力・資本構成)を把握するために用いる。B/Sとも呼ばれる。
- 代替キー(alternate keys)
- 外部システムのキー(例: 注文番号)で Dataverse レコードを一意に特定する仕組み。GUID 主キーを知らない外部連携に使う。
- 代替テキスト(alt text)
- スクリーンリーダー向けにビジュアルの内容を説明するテキスト。アクセシブルなレポート設計の基本で、タブ順序やコントラストと併せて用いる。
- 台帳(Ledger in Azure SQL)
- 改ざん耐性のある台帳機能。暗号学的に連結したダイジェストで履歴を検証可能にし、更新可能台帳と追加専用台帳の表を提供する。
- 大規模セマンティックモデル形式
- 大きなモデルを扱うためのストレージ形式。サイズ上限を引き上げ、XMLA 書き込みや一部の高度機能を可能にする。
- 大規模言語モデル(LLM)
- 膨大なテキストで学習し、次のトークンを確率的に予測して文章を生成するモデル(Transformer基盤)。
- 第4正規形
- BCNF を満たした上で、自明でない多値従属を持たないことを要件とする正規形。互いに独立した1対多の関係が1つの表に同居していると生じる、無関係な組合せの重複挿入を排除する。
- 第5正規形
- すべての結合従属性が候補キーによって含意される状態まで、それ以外の結合従属性を無損失分解で除去した正規形。実務上の正規化の到達点とされるが、理論上はさらに6NF等が存在する。結合従属性とは、表を複数に分割して再結合しても元の内容に一致する性質。
- 単一障害点(SPOF)
- そこが壊れるとシステム全体が止まる箇所。マルチ AZ 配置・冗長化・ロードバランサ・自動フェイルオーバーで排除する。可用性設計の出発点=SPOF を洗い出して潰す。
- 担当者(assignee)
- Issue や Pull Request の対応責任者として割り当てる 1 名以上のユーザー。検索修飾子 assignee: で絞り込め、通知やダッシュボードでの自分のタスク把握に使う。レビュー担当を示す reviewer とは役割が異なる(reviewer は変更内容の査読者)。
- 探索アルゴリズム
- 多数のデータの中から目的の値を見つけ出す手順のこと。先頭から順に1つずつ調べる線形探索(逐次探索)と、整列済みデータを半分ずつ絞り込む二分探索が代表例で、二分探索の方が高速に見つけられる。
- 探索空間(search space)
- 調整するハイパーパラメーターとその候補範囲(離散 choice・連続 uniform/loguniform 等)の定義。
- 端末切断後の実行継続(nohup/screen/tmux)
- ログアウトや SSH 切断後も処理を継続させる手段。nohup は端末切断(SIGHUP)を無視して実行を続ける。screen/tmux は仮想端末で、セッションをデタッチ/再アタッチできる。
- 弾力性(Elasticity)
- 負荷に応じて自動で能力を増減すること(オートスケール)。スケーラビリティを自動化したもの。
- 知る必要性(Need-to-know)
- 最小権限の原則が「業務遂行に必要な最小限の権限」を対象とするのに対し、知る必要性は権限の有無だけでなく「その業務上、実際に知る必要がある情報」だけにアクセスを絞る考え方。同じロールの権限を持っていても、担当外の案件情報などは業務上不要であれば閲覧させないなど、より粒度の細かい情報アクセス制御に用いる。
- 知識のカットオフ
- LLM が学習した時点までしか知識を持たない限界。以降に変わったライブラリ仕様などを知らないことがあるため、最新ドキュメントで確認する。
- 知的財産権
- 発明・著作物・デザイン・商標などの創作的な成果を保護する権利の総称。大きく著作権と産業財産権(特許権・実用新案権・意匠権・商標権)に分けられる。
- 地理的分散
- サーバーやデータセンターを複数の地域に分散配置すること。特定地域の災害・停電など広域障害があってもサービスを継続できるようにする、回復性を高める手段の一つ。
- 着信キュー(call queue)
- 着信を担当者グループ(エージェント)へ振り分けの方式(順番・一斉呼出・最長アイドル等)に従って分配し、応答されるまで保留音や案内を流す Teams 電話機能。resource account を割り当てて電話番号を持たせ、コールセンターやヘルプデスクの一次受付として使われることが多い。
- 中間者攻撃(Man-in-the-Middle)
- 通信を行う二者の間に攻撃者が割り込み、双方には正規の相手と直接通信しているように見せかけながら、通信内容の盗聴・改ざんを行う攻撃の総称。ARPスプーフィングや不正DHCPサーバによるゲートウェイ偽装、DNSキャッシュポイズニングなどが手口となる。相互認証(デジタル証明書の検証等)や経路の暗号化・完全性保護で対策する。
- 中小受託取引適正化法
- 委託事業者が中小受託事業者へ発注する取引の適正化を図る法律(旧・下請法。2026年〈令和8年〉施行予定、シラバスVer.6.5で名称改定)。名称変更に伴い旧「親事業者/下請事業者」は「委託事業者/中小受託事業者」に改称された。代金の支払遅延・不当な減額・買いたたきなどを禁止するほか、割引困難な手形(サイトの長い手形等)による支払など支払手段を規制する(手形払いを一律禁止するものではない)。
- 著作権
- 小説・音楽・プログラムなどの著作物を創作した時点で自動的に発生する権利で、特許権と異なり登録の手続きは不要。プログラムの著作権は原則としてプログラムを創作した者に帰属する(職務著作を除く)。
- 調査ツール(investigation tool)
- セキュリティインシデント(フィッシング拡散など)でログを横断的に検索し、該当メッセージの一括削除やデバイス対処などの一括アクションをとるツール。一括アクションは強力なため影響範囲を確認してから実行する。
- 調査パッケージ
- Defender for Endpoint でデバイスからフォレンジック用の情報(プロセス一覧・ネットワーク接続・レジストリ・自動起動項目・ログ等)を一括収集する機能。ライブレスポンスの対話的操作と異なり、あらかじめ決まった項目を非対話でまとめて取得する調査用の一括収集操作。
- 調達(計画と実施)
- システム開発などを外部のベンダーに依頼するために、必要なものを選んで手に入れる一連の活動。まず何をどのように調達するかを決める「計画」を立て、次にRFI(情報提供依頼)やRFP(提案依頼)、相見積りなどを通じて発注先を選び契約する「実施」を行う。
- 長期保持(LTR)
- 週次/月次/年次のバックアップを最大10年保持し、コンプライアンス要件に応えるバックアップ戦略。
- 直列化可能性
- 複数のトランザクションを並行実行した結果が、それらを何らかの順序で1つずつ直列実行した結果と一致するという性質。隔離性水準 SERIALIZABLE はこの性質を保証し、あらゆる読取り異常(ダーティリード・反復不能読取り・ファントムリード)を防ぐ最も厳格な水準。
- 追加(Power Query)
- Power Query で、列構成が同じ複数のテーブルを縦方向に積み重ねて 1 つのテーブルにする操作(SQL の UNION 相当)。列名や順序が完全に一致していなくても列名でマッチングして結合されるが、型の不一致はエラーになりうる。月次データの結合などに使う。
- 通貨列
- 金額を格納する列。通貨の種類や為替レートを扱え、金額計算に適した精度を持つ。
- 通知(Notifications コネクタ)
- Power Automate モバイルアプリへプッシュ通知を送るコネクタ。フローの結果をユーザーへ知らせるのに使う。かつて備えていたメール通知アクションは現在提供終了(retired)で、メール送信は Office 365 Outlook 等の別コネクタを使う。
- 通話ポリシー(calling policies)
- ユーザーが利用できる通話機能を制御するポリシー。発信・着信転送・委任(delegate)・通話の録音や文字起こし可否などを、ユーザーやグループ単位で細かく許可/禁止する。voicemail policies や voice routing policy と並ぶ「voice policies」群の一部を成す。
- 定額契約(FP)
- あらかじめ合意した総額を支払う契約類型。要件が明確に固まっている場合に適し、コスト超過のリスクはベンダー側が負う。要件が流動的な探索的な開発に適用するとベンダーが過大なリスクプレミアムを乗せる、あるいは品質低下を招く点に注意が必要。
- 定期/継続バックアップと PITR
- Cosmos DB の 2 つのバックアップモード。定期は間隔スナップショットを Geo 冗長に保持し復元は Microsoft サポート経由。継続はポイントインタイム復元(PITR)で保持期間内の任意時点(秒単位)へセルフサービス復元でき、誤削除/誤更新の巻き戻しに強い。復元は新しいアカウントへ行う。
- 定義域(ドメイン)
- 属性が取りうる値の集合。例えば「性別」属性の定義域は{男,女,その他}のように定める。定義域を明示することで、無効な値の混入を防ぎデータの整合性を保てる。
- 提案のライフサイクル
- 文脈変化→プロンプト生成→モデル生成→候補提示→受け入れ/却下→新しい文脈で次の提案、という循環。受け入れた内容は次の文脈に影響する。
- 適合性パック(Conformance Pack)
- 複数の Config ルールと修復アクションを1つのテンプレートにまとめ、アカウントや組織全体へ一括デプロイする仕組み。PCI DSS や CIS ベンチマーク等の共通基準をまとめて適用する際に使い、個別ルールを1つずつ設定する手間を省く。
- 適用宣言書(SoA)
- ISO/IEC 27001の附属書A(Annex A)に列挙された管理策のうち、どれを自組織に適用するか/除外するかとその理由を明記した文書。リスクアセスメントの結果に基づいて作成し、ISMS認証審査の中心的な確認対象になる。
- 添付(コントロール)
- ファイルを添付・表示するコントロール。フォームに置いてレコードへドキュメントや画像を添付できる。
- 転移学習とデータ拡張
- 事前学習済みモデルを少量データで適応する。度合いは、データ極小/近ドメイン=特徴抽出器として凍結(最終層のみ)、中程度=上位層の部分微調整、十分/遠ドメイン=全層を低 LR で微調整。過学習対策はデータ拡張(回転/反転/切り抜き)・バッチ正規化・ドロップアウト・early stopping。SageMaker JumpStart で事前学習済みモデルを微調整できる。
- 転送時の暗号化(in transit)
- ネットワーク経路を通過中のデータを暗号化すること。多くの場合TLSで通信を保護する。保管時の暗号化と組み合わせて初めて、データのライフサイクル全体(保存中・移動中)を防御できるため、両方を満たすのがセキュリティの基本要件となる。
- 伝送時間
- データをネットワーク上で送信するのにかかる時間で、データ量を回線の伝送速度(帯域幅)で割って算出される。実際の応答時間はこれに伝搬遅延や処理時間を加えたものとなり、回線の実効速度は理論値に伝送効率を掛けて評価する必要がある。
- 伝送速度
- 単位時間あたりに伝送できるビット数を表す指標で、bps(ビット毎秒)で表される回線・インタフェースの理論上限(帯域)を指す。実効的なデータ転送量であるスループットとは異なり、伝送速度はプロトコルオーバーヘッドや輻輳の影響を受けない物理・データリンク層の公称値である点が問われる。伝送効率(伝送速度×伝送効率=実効転送速度)の計算問題でも頻出。
- 伝送媒体(UTP・同軸ケーブル・光ファイバ)
- 有線ネットワークの伝送媒体。UTP(非シールドツイストペア)は銅線を撚り合わせてノイズの影響を抑えたケーブルでLAN配線の主流(最長約100m)、同軸ケーブルは中心導体を編組シールドで覆った古い規格、光ファイバは光信号で伝送し電磁干渉を受けず長距離・高速な通信に使われる(レーザー光を使うシングルモードファイバは長距離向け、LED光源のマルチモードファイバは短中距離向け)。
- 伝送符号化
- デジタルデータのビット列を物理媒体上で伝送可能な電気信号や光信号の波形に変換する方式で、マンチェスタ符号やNRZ、4B/5B、8B/10Bなどが代表例である。受信側でのクロック同期の取りやすさや直流成分の抑制、伝送効率(符号化効率)が方式選定の観点となり、規格(10BASE-T、1000BASE-T等)ごとに採用符号化方式が異なる。
- 電気電子回路の基礎(電流・電圧・抵抗)
- 電気回路を流れる電気の量が電流、電気を押し流す力が電圧、電流の流れにくさが抵抗。この3つの関係を表すのがオームの法則(電圧=電流×抵抗)で、ハードウェアの動作を支える基本的な物理法則である。
- 電子署名
- 公開鍵暗号の仕組みを利用して、電子文書の作成者本人であることの証明(本人性)と、文書が改ざんされていないことの証明(完全性)を行う技術。
- 電子署名法
- 一定の要件(本人だけが行うことができる・改変の有無を確認できる等)を満たす電子署名が付された電磁的記録は、真正に成立したものと推定するという法律。電子契約が紙の契約書と同等の法的効力を持つための根拠となっている。
- 登録トークン(registration token)
- セッションホスト(VM)をホストプールに参加させるためのトークン。AVD エージェントがこのトークンで登録する。有効期限があり、切れているとセッションホストが参加できない。
- 登録状態ページ(ESP)
- Autopilot などの展開中に、構成の進捗状況やブロックされたアプリ/ポリシーを表示するページ。
- 登録制限(Intune)
- デバイス プラットフォーム(iOS/Android/Windows 等)やバージョン、個人所有デバイス(BYOD)の登録可否をポリシーで制限する仕組み。既定の制限と、特定グループ向けのカスタム制限を優先順位付けして適用でき、非対応の古い OS や未許可プラットフォームからの登録をブロックできる。
- 統計(Warehouse)
- 列の分布情報。クエリオプティマイザーが効率的な実行計画を選ぶのに使う。古い/欠落した統計は遅いクエリの原因になる。
- 統合キャッシュ(integrated cache)
- 読み取りが非常に多くデータがあまり変わらないワークロードで、専用ゲートウェイ経由でポイント読み取りやクエリ結果をキャッシュし RU を大幅に削減する Cosmos DB の機能(結果整合の許容が前提)。クエリ効率を上げるインデックスとは役割が異なる。
- 統合変更管理
- 変更要求を受け付け、影響範囲(スコープ・スケジュール・コスト・品質)を評価し、変更管理委員会などで承認・却下・保留を決定してベースラインへ反映するプロセス。無秩序な変更(スコープクリープ)を防ぎ、変更の影響を組織全体で一貫して管理する点で重要。
- 統制された展開(ガバド・ロールアウト)
- 生成 AI を本番へ安全に出す運用。API ゲートウェイ/プロキシで入口を一元化(認証・レート制限・ロギング・モデル切替)、CI/CD に評価ゲートを組み込み、A/B・カナリアで段階展開する。問題時は即ロールバック。
- 統制の3類型(予防統制・発見統制・是正統制)
- 内部統制を機能面で分類した3類型。予防統制は誤りや不正の発生を未然に防ぐ統制(承認権限の設定・職務分掌・アクセス制御など)、発見統制は発生した誤りや不正を検知する統制(証憑突合・ログ監視・例外レポートの確認など)、是正統制は発見された問題を回復し再発防止を図る統制を指す。監査人は各統制の組合せと網羅性を評価する。
- 統制の種類(予防的/検出的/対応的)
- セキュリティ統制の分類。予防的=そもそも起こさせない(SCP・IAM・SG)。検出的=起きたことを見つける(Config・GuardDuty・CloudTrail)。対応的(是正)=自動で直す(SSM Automation・Config 修復)。多層で組み合わせる。Control Tower のガードレールもこの考え方。
- 統制リスク(control risk)
- 内部統制が存在してもなお、重要な誤りや不正を防止または発見できないリスク。監査人は統制の整備状況・運用状況を評価してこのリスクの水準を判断し、統制リスクが高いと評価された領域では実証手続をより厚くする。固有リスクと並び、監査人にとっては「所与」として評価する対象である。
- 透過的データ暗号化(TDE)
- Azure SQL のデータベースを保存時(ファイル・バックアップ)に暗号化する機能で、既定で有効。アプリ側の改修は不要(透過的)で、処理時はサーバー上で復号されるため DB 管理者やサーバーは平文を扱える。保護キーは既定のサービス管理キーから CMK(BYOK)へ変更できる。「保存時」を守るのが役割で、転送時は TLS が担当する。
- 動的グループ メンバーシップ規則
- OS や所有形態などの属性に基づいて、条件に合うデバイス/ユーザーを自動的にグループへ追加・削除する規則(手動固定の割り当てグループに対する自動グループ化)。
- 動的データマスク
- 実データは変えずに、クエリ結果の表示だけをマスクして機微情報を隠す。UNMASK 権限を持つユーザーには実値が見える。
- 動的データマスク(Fabric)
- 権限のない利用者にだけ、データを伏字(例:メールの一部)で見せる機能。元データは変えず表示時にマスクする。
- 動的モデルルーティング
- 入力の分類結果や設定に応じて、リクエストごとに使うモデルを動的に切り替える仕組み。簡単な問い合わせは小型、難問は大型へ振り分けてコストと品質を両立する。AppConfig 等で再デプロイなしにルーティング規則を更新できる。
- 動的ルーティングと静的ルーティング
- 動的ルーティングはルーティングプロトコルが経路情報を自動的に交換・学習し、トポロジ変化に追従して経路表を更新する方式。静的ルーティングは管理者が経路を手動設定し、変更がない限り固定される。動的は運用負荷が低く大規模網向き、静的は経路が単純・少数の環境やスタブネットワークでオーバーヘッドがなく予測可能という特徴を持つ。
- 動的ルーティングモード(グローバル/リージョナル)
- Cloud Router が学習した BGP 経路を伝播する範囲を決める VPC の設定。リージョナルは同一リージョンのみ、グローバルは全リージョンへ伝播する。複数リージョンへ広げるにはグローバルが必要。
- 動的管理ビュー(DMV)
- サーバー/データベースの「今この瞬間」の内部状態(待機・ブロッキング・インデックス使用状況等)を SQL で参照できるビュー。
- 動的計画法
- 問題を部分問題に分割し、それぞれの計算結果を記憶(メモ化)して再利用することで、同じ部分問題を重複して解く無駄を省き計算量を削減するアルゴリズム設計技法。フィボナッチ数列や最短経路問題、ナップサック問題など、部分問題の重複が多い問題で特に効果を発揮する。
- 動的書式文字列
- メジャーの表示書式(通貨・パーセントなど)を条件に応じて DAX で動的に変える機能。計算グループと併用することが多い。
- 同一オリジンポリシー(Same Origin Policy)
- ブラウザの基本的なセキュリティ機構で、あるオリジン(スキーム・ホスト・ポートの組)から読み込まれた文書やスクリプトが、異なるオリジンのリソースへアクセスすることを原則制限する。必要な範囲で緩和する仕組みがCORSである。
- 同期/非同期レプリケーション
- 同期レプリケーションは RPO≈0 だが書き込み遅延が増える。非同期は遅延が小さいが障害時にデータ損失の可能性がある。RPO 要件で選ぶ。
- 同期スライサー
- 複数のレポートページでスライサーの選択を連動させる機能。あるページの選択を他ページへ引き継ぐ。
- 同期レプリケーション
- 書き込みを複製先が確定するまで待って応答する方式。障害時のデータ損失がゼロ(RPO 0)だが書き込み遅延が増える。RDS マルチ AZ 等で使われる。
- 同値分割と限界値分析
- ブラックボックステストの代表技法。同値分割は入力を同じ振る舞いが期待されるグループ(同値クラス)に分け各クラスから代表値を選ぶ。限界値分析はエラーが起きやすい境界とその前後の値を重点的にテストする。両者を組み合わせてテストケース数を絞りつつ欠陥検出率を高める。
- 導体と絶縁体(半導体)
- 導体は電気をよく通す物質(銅や鉄などの金属)で、配線に使われる。絶縁体は電気をほとんど通さない物質(ゴムやガラスなど)で、感電防止の被覆などに使われる。両者の中間の性質をもち、条件によって電気の通しやすさが変わる物質が半導体で、ICなどの電子部品の材料になる。
- 特許戦略
- 自社の研究開発成果をどの範囲・タイミングで特許出願し、公開(独占による優位確保)と秘匿(ノウハウとして非公開のまま模倣を防ぐ)のどちらを選ぶかを経営判断として設計する戦略。ストラテジストは、コア技術は特許網で防御しつつ関連規格は他社に無償・安価に開放して市場全体を拡大するオープン&クローズ戦略のように、独占と普及のバランスを事業戦略に応じて判断する。
- 特権ID管理
- システム管理者権限(root/Administrator等)を持つ特権IDを一般ユーザーIDと分離し、利用申請・承認・払い出し・利用記録(証跡)・返却までを厳格に管理する仕組み。特権ID管理製品によるパスワードの自動ローテーションやワンタイム化で、ID共有や恒久的な保持によるリスクを下げる。
- 特権アクセスワークステーション(PAW)
- メールやブラウジングを排した専用の堅牢な端末からのみ管理操作を許す設計。管理端末の汚染による認証情報奪取を防ぐ。MFA/PIM だけでは防げない「管理者の入口」を隔離する。
- 特殊デバイス(Intune)
- Teams Rooms や Microsoft HoloLens 2、Surface Hub など、一般的な PC/モバイルとは異なる用途特化型デバイスを指す Intune の正式な管理カテゴリ「Specialty devices」(Intune 管理センターの Devices > Specialty devices)。専用の構成プロファイルやアプリ配布方法が用意されており、通常のプラットフォーム別(Windows/Android/iOS)のデバイス管理とは別に、これらの用途特化型デバイスをまとめて管理する。
- 特殊パーミッション(SUID/SGID/スティッキービット)
- 特殊なパーミッションビット。SUID(4000)は実行時にファイル所有者の権限で動く(例 passwd)。SGID(2000)は実行ファイルではグループ権限、ディレクトリに付けると新規ファイルがそのグループを継承する。スティッキービット(1000)はディレクトリ内のファイルを所有者しか削除できなくする(例 /tmp)。
- 特性要因図
- 問題(特性)に対する原因(要因)を、人・機械・方法・材料などのカテゴリに分けて魚の骨のような形に整理する図。根本原因分析に用い、対症療法ではなく真因に対処する判断を支援する点で重要。
- 特徴量エンジニアリング(ビニング/対数変換/PCA)
- モデル性能を高める特徴量の作成・変換。連続値のビニング(離散化)、歪んだ分布の対数変換、PCA による次元削減、相関や重要度に基づく特徴量選択を行う。
- 特徴量エンジニアリングと埋め込み/RAG
- 特徴量エンジニアリングは学習・サービング向けにデータを整える作業。生成 AI では非構造化データを埋め込み(embeddings)にし、検索拡張生成(RAG)で関連情報を取り出して回答に使う。
- 特徴量とラベル
- 特徴量=学習に使う入力、ラベル=教師あり学習で与える正解。
- 特定時点復元(PITR)
- 自動バックアップ(フル/差分/ログ)を使い、保持期間(既定7日・最大35日)内の任意時点に新しい DB として復元する機能。
- 独自コンテナ(BYOC)と ECR
- 独自の学習/推論コードを Docker イメージにし、Amazon ECR に保存して SageMaker で実行する方式。組み込みアルゴリズムで足りない要件に対応する。
- 独立性
- ACID特性の一つで、複数のトランザクションを同時実行しても、それぞれが他のトランザクションの影響を受けずに実行されたかのような結果を保証する性質。分離レベルの設定によって、ダーティリード等の異常現象をどこまで許容するかを制御する。
- 読み取りスケールアウト
- Business Critical / Hyperscale で、読み取り専用のセカンダリレプリカに読み取り負荷を振り分け、主レプリカの負荷を下げる機能。接続文字列の ApplicationIntent=ReadOnly で利用する。
- 読み書き分離
- 書き込みは常にプライマリインスタンスへ送り、読み取りはリードレプリカへ振り分けて負荷を分散するデータベースアクセスパターン。アプリ側またはRDS Proxyのようなプロキシ層で接続先を出し分ける。レプリカは非同期複製のため、書き込み直後の読み取りで反映漏れ(レプリケーションラグ)が起こりうる点に注意する。
- 突合・照合法
- 性質の異なる二つ以上の記録やデータ(例:入力伝票と処理結果一覧、在庫記録と実地棚卸結果)を突き合わせ、内容の一致・不一致を確かめる監査技法。処理の正確性や網羅性を客観的に検証でき、差異が見つかった場合はその原因を追跡調査する端緒となる。
- 内外製分析
- 必要な作業・成果物を自社で内製するか外部から調達するかを、コスト・専門性・スケジュール・戦略的重要性の観点から比較検討する分析。調達マネジメント計画の初期段階で行い、以降の契約類型の選択にも影響する点で重要。
- 内部監査と外部監査
- 内部監査は組織内に設置された監査部門が実施する監査で、経営者への直接報告や監査部門の組織的独立性の確保によって客観性を担保する。外部監査は組織に属さない第三者(監査法人や外部の専門家)が実施する監査で、利害関係を持たない立場から独立性を確保しやすい。両者は目的や独立性の確保方法が異なるが、相互補完的に利用されることも多い。
- 内部統制
- 業務が適正・効率的に遂行されるよう、企業が自ら業務プロセスに組み込む仕組み・体制。目的は①業務の有効性・効率性②報告(財務報告)の信頼性③事業活動に関わる法令等の遵守④資産の保全の4つで、統制環境・リスクの評価と対応・統制活動・情報と伝達・モニタリング・ITへの対応の6つの基本的要素から構成される(金融庁実施基準/COSOフレームワーク)。整備・運用の責任は経営者にある。
- 内部統制の6要素(J-SOX実施基準)
- 日本のJ-SOX(金融商品取引法の内部統制報告制度)の実施基準が定める内部統制の構成要素。COSOの5要素(統制環境・リスクの評価と対応・統制活動・情報と伝達・モニタリング)に、IT環境への対応を独立した要素とした「ITへの対応」を加えた6要素で構成される。監査人はこの6要素で財務報告に係る内部統制の整備・運用状況を評価する。
- 内部不正
- 従業員や委託先など組織内部の関係者が、正規の権限を悪用して情報を持ち出す・改ざんする・システムを妨害するなど意図的に引き起こす不正行為。外部からの攻撃より検知しづらく、動機(不満・金銭)と機会(過剰な権限)と正当化の3要素(不正のトライアングル)で説明されることが多い。アクセスログの監視や職務分掌が対策の柱。
- 二次リスク
- あるリスクへの対応策を実施したことによって新たに発生するリスク。例えば下請けへの再委託(転嫁)が新たな供給者管理リスクを生むように、対応策自体が生むリスクを見落とさず評価することが、リスク対応の完全性を保つ上で重要。
- 二分探索(バイナリサーチ)
- 整列済みのデータ列に対し、探索範囲の中央値と目的の値を比較して範囲を半分ずつに絞り込んでいく探索方法。データが整列されていることが前提条件で、線形探索より高速に見つけられる。
- 二要素認証(2FA)
- パスワードに加え第二の要素で本人確認する仕組み。パスキー等が推奨。組織で必須化できる。
- 日付ディメンション
- 連続した日付と暦の属性(年/四半期/月/曜日など)を持つ専用ディメンション。タイムインテリジェンス(前年比など)の前提になる。
- 日付テーブル(Power BI)
- タイムインテリジェンスに必要な連続した日付のテーブル。「日付テーブルとしてマーク」して使う。
- 日付と時刻列
- 日付や日時を格納する列。日付のみ/日付と時刻の形式やタイムゾーンの扱いを設定できる。
- 日付選択(Date picker)
- カレンダーから日付を選ばせるコントロール。日付列の入力に使い、表記ゆれや無効な日付を防ぐ。
- 入出力インタフェース(USB・HDMI・Bluetooth)
- コンピュータと周辺機器をつなぐための接続の規格。USBはマウスやメモリなど幅広い機器を有線でつなぐ汎用規格、HDMIは映像と音声をまとめてディスプレイ等へ伝送する規格、Bluetoothはケーブル不要で近距離の機器を無線接続する規格(イヤホンなど)。
- 入出力装置
- コンピュータへデータを入力する装置(キーボード・マウス・スキャナー等)と、処理結果を出力する装置(ディスプレイ・プリンター等)の総称。IoT機器ではセンサーが入力装置、アクチュエーターが出力装置として働く。
- 入力/出力バインディング(Functions)
- 関数とデータソースを宣言的につなぐ仕組み。入力バインディングで読み込み、出力バインディングで書き込みを、コードを書かずに接続できる。
- 入力の再整形(前処理)
- 曖昧・不揃いなユーザー入力を、生成 AI が扱いやすい形へ整える前処理。Bedrock によるリフレーズ(質問の言い換え/明確化)や Comprehend による正規化・言語判定を挟み、検索精度と回答品質を上げる。
- 任意アクセス制御(DAC)
- 情報の所有者が自らの裁量で、誰にどのアクセス権を与えるかを決められるアクセス制御方式。柔軟だが所有者の判断ミスや不注意な権限付与に弱く、システムが一元的に強制する強制アクセス制御(MAC)と対をなす。
- 認可フロー(OAuth2/OIDC)
- トークン取得の流れ。ユーザー対話は認可コードフロー、デーモン/サービス間はクライアント資格情報フローを使う。用途で正しく選ぶ。
- 認証(AuthN)
- 「あなたは誰か」を確認する本人確認。認可より先に行う。
- 認証VLAN
- IEEE802.1X等の認証結果に応じて、スイッチが端末の接続先VLANを動的に切り替える仕組み。認証成功時は利用者の所属や権限に応じた業務VLANへ、未認証・認証失敗時はインターネット接続や社内リソースへのアクセスを制限した検疫VLANやゲストVLANへ自動的に収容する。
- 認証コンテキスト
- 特定の操作やアプリに追加の認証要件(例:フィッシング耐性 MFA)を求めるためのラベル。Conditional Access や保護されたアクションと組み合わせ「最も危険な操作だけ強い認証」を実現する。
- 認証メソッド(trust/md5/scram-sha-256/peer)
- pg_hba.conf で指定できる代表的な認証方式。trust は無条件に許可、md5 と scram-sha-256 はパスワードによる認証(scram-sha-256 がより安全な既定方式)、peer は OS のユーザー名で認証するローカル接続向けの方式。
- 認証情報レポート
- アカウント内の全 IAM ユーザーについて、パスワードの有無・MFA 有効化状況・アクセスキーの作成日や最終使用日をまとめて出力する CSV レポート。4 時間に 1 回まで生成でき、未使用の認証情報を棚卸しして無効化する監査作業の起点になる。
- 認証方式(MFA・パスワードレス)
- 本人確認の手段。多要素認証(MFA)やパスワードレス(FIDO2 セキュリティキー・Authenticator・Windows Hello 等)など、パスワード単独より強い方式を用いる。
- 認証要素
- 本人確認の根拠の種類。知っているもの(パスワード)、持っているもの(トークン/電話)、そのもの(生体)の 3 カテゴリ。複数を組み合わせると MFA になる。
- 能動的偵察・受動的偵察
- 攻撃対象について情報収集する偵察行為。能動的偵察はポートスキャン等で対象へ直接通信を送り応答から情報を得る手法で検知されうる一方、受動的偵察は公開情報(企業サイト・SNS・DNS登録情報等)の収集にとどまり対象に気付かれにくい。
- 排他制御
- 複数の利用者・処理が同じデータへ同時に更新をかけることで生じる矛盾を防ぐため、データにロックをかけて他の処理からの同時アクセスを制限する仕組み。
- 配信セマンティクス(少なくとも1回/正確に1回)
- メッセージ配信の保証レベル。少なくとも1回(at-least-once)=重複し得る(標準 SQS・要べき等処理)。正確に1回(exactly-once)=重複も欠落もなし(SQS FIFO)。最大1回(at-most-once)=欠落し得るが重複なし。設計はべき等性で重複に耐える。
- 配列とリスト
- 複数のデータを並べて扱う基本的なデータ構造。配列は連続した領域に要素を並べ、添字で任意の要素へ即座(O(1))にアクセスできるが、途中への挿入・削除は後続要素の移動を伴い高コスト。リスト(連結リスト)は各要素が次の要素への参照(ポインタ)を持つ構造で、挿入・削除はポインタの付け替えだけで済むが、任意要素へのアクセスは先頭からたどるためO(n)になる。
- 媒体アクセス制御方式(CSMA/CD・CSMA/CA)
- 共有媒体でのアクセス制御方式。CSMA/CD(衝突検知)は半二重の有線イーサネットで衝突を検知して再送する方式。CSMA/CA(衝突回避)は衝突検知が困難な無線LANで、送信前に一定時間待機・確認して衝突を避ける方式。デュプレックスミスマッチ(片側半二重・片側全二重)ではレイトコリジョン・FCSエラーが多発する。
- 発見リスク(detection risk)
- 監査人が実施する監査手続によっても、重要な不備や誤りを見逃してしまうリスク。固有リスクと統制リスクが監査人にとって所与であるのに対し、発見リスクは監査手続の種類・範囲・時期(試査の程度など)を調整することで監査人自身がコントロールできる唯一のリスクであり、固有・統制リスクが高い領域ほど発見リスクを低く抑える必要がある。
- 半加算器と全加算器
- 半加算器は2つの1ビットを加算し和と桁上げを出力するが下位からの桁上げ入力を持たない回路。全加算器は下位桁上げ入力も加えた3入力で和と桁上げを出力し、半加算器2個とORゲートで構成できる。多ビット加算器は全加算器を連結して作る。
- 半構造化データ
- タグやキーで構造を持つが固定スキーマに縛られない柔軟なデータ。例:JSON、XML。
- 反復不能読取り
- 同一トランザクション内で同じ行を2度読んだ際、間に別のトランザクションが更新・コミットしたために値が変わってしまう読取り異常。READ COMMITTED までは発生しうり、REPEATABLE READ 以上で防止される。
- 汎用監査ソフトウェア
- 監査人が本番データを直接読み込み、全件抽出・並べ替え・集計・突合などを行える汎用のCAATツール。母集団全件を対象とした精査的な検証に向き、サンプリングでは発見しにくい異常値や例外パターンの網羅的な検出に利用される。特定業務に依存しない汎用性が特徴。
- 番号プロビジョニング(Calling Plan / Operator Connect / Direct Routing)
- Teams Phone の電話番号入手方式。Calling Plan は Microsoft が番号と PSTN 通話を提供、Operator Connect は認定通信事業者と連携、Direct Routing は自前の SBC で既存事業者に接続する。
- 否認防止
- 情報セキュリティの拡張要素の一つで、ある行為やメッセージの送信を後になって本人が「やっていない」と否認できないようにする性質。デジタル署名やタイムスタンプによって証拠を残し、電子取引の法的な証跡確保に用いられる。
- 悲観ロック
- 更新前に対象へロックを取得し、保持している間は他のトランザクションを待たせる競合制御方式。競合が頻発する状況では楽観ロックより安全だが、並行性が下がりデッドロックのリスクがある。複数ノードにまたがる分散ロックはDynamoDB等を使って実装する。
- 秘密度ラベル
- データを分類し、暗号化や利用制限などの保護を適用する仕組み。ラベルはファイルに付随し社外でも保護が効く。
- 非リレーショナル(NoSQL)
- 固定スキーマに縛られず柔軟に保存するDB。キー値/ドキュメント/列ファミリ/グラフの4種類。
- 非機能要求グレード
- IPAが公開する、可用性・性能/拡張性・運用保守性・移行性・セキュリティ・システム環境/エコロジーといった非機能要求を、発注者と受注者が段階的なグレードとして具体的に合意するための体系・ツール群。抽象的で見落とされやすい非機能要求を項目とレベルで可視化し、要求水準の認識齟齬やコスト見積りの食い違いを防ぐ。システムアーキテクトはこれを用いて非機能要求を漏れなく引き出し、アーキテクチャ設計の前提として確定させる。
- 非機能要件
- 機能そのものではなく、性能・可用性・セキュリティ・保守性など、システムの品質面に関する要件。要件定義で機能要件と併せて明確にしておく必要がある。
- 非構造化データ
- 決まったスキーマがないデータ。ファイル/オブジェクトとして保存。例:画像・動画・音声・文書。
- 非重複チャネル
- 2.4GHz帯の無線LANでチャネル同士の電波干渉を避けるために選ぶ、周波数が重ならない組み合わせ(一般に1・6・11ch)。隣接するアクセスポイントに異なる非重複チャネルを割り当てることで通信品質を保つ。
- 非正規化
- 正規化したテーブルをあえて結合・冗長化し、読み取り/分析を速くする手法。分析基盤では結合コストを下げるためによく使う。
- 非同期データ処理
- リクエストへの応答を待たせずに、時間のかかる処理をキューやメッセージングシステム経由で後から実行する方式。処理の疎結合化とスループット向上に役立つ。
- 非同期レプリケーション
- 先に応答し、後から複製先へ反映する方式。書き込み遅延は小さいが、障害時に未反映分のデータ損失が起こりうる。リードレプリカやクロスリージョン複製で使われる。RPO 要件で同期と使い分ける。
- 非同期処理(生成 AI)
- 時間のかかる生成や大量バッチを、リクエスト/レスポンスを切り離して捌く設計。SQS にジョブを積み Lambda ワーカーで処理し、結果は保存/通知で返す。タイムアウト回避・スパイク吸収・コスト平準化に有効で、Bedrock のバッチ推論とも組み合わせる。
- 非排他的バックアップ
- バックアップラベルがサーバの共有メモリで管理されるため、pg_backup_start()/pg_backup_stop()(PostgreSQL 15 より前は pg_start_backup()/pg_stop_backup())を呼び出したセッションがクラッシュしても安全に扱える方式。PostgreSQL 9.6 で導入され、排他的バックアップは 15 で削除されたため現在はこの方式のみ。
- 標準ACLと拡張ACL
- 標準ACLは送信元IPアドレスのみを条件に許可/拒否を判定するため、宛先に近い側に配置しないと意図せず他の通信まで遮断しやすい。拡張ACLは送信元/宛先IPアドレスに加えプロトコル種別・ポート番号でも判定できるため、送信元に近い側に置いて必要な通信だけを早期にフィルタリングできる。
- 標準化団体(ISOとJIS)
- 規格の統一を図る標準化団体。ISO(国際標準化機構)は国際的な標準規格を策定する機関で、ISO 9001(品質マネジメント)やISO/IEC 27001(情報セキュリティマネジメント)などがある。JIS(日本産業規格)は日本国内の産業標準で、国際規格に整合して制定されることが多い。相互運用性の確保と取引の円滑化が標準化の目的である。
- 標準入出力(stdin/stdout/stderr)
- すべてのコマンドが持つ3本のストリーム。標準入力(0)・標準出力(1)・標準エラー出力(2)。この3本をリダイレクトやパイプで付け替えるのが Linux のテキスト処理の基本。
- 標的型攻撃
- 特定の組織や個人を狙い、業務に関係あるように装ったメール(標的型攻撃メール)などで機密情報の窃取やシステム破壊を狙う攻撃。不特定多数を狙うばらまき型の攻撃とは異なる。
- 標的型攻撃メール訓練
- 実際の攻撃を模した疑似的な標的型攻撃メールを従業員へ送信し、開封率やリンククリック率を測定して意識向上と対応手順の定着を図る教育訓練。結果を集計し、開封してしまった従業員への追加教育や、不審メール報告のフローの周知に活用する。
- 標本化と符号化
- アナログ信号をデジタル化するA/D変換は標本化→量子化→符号化の3段階から成る。標本化は連続信号を一定間隔(標本化周期)で切り出す処理で、標本化定理により元信号の最大周波数の2倍以上の標本化周波数が必要。量子化は標本値を離散的な段階値に丸める処理。符号化はその量子化値を2進数のビット列に割り当てる処理。
- 標本化定理(ナイキストの定理)
- アナログ信号を標本化(サンプリング)してデジタル化する際、原信号に含まれる最高周波数成分の2倍以上のサンプリング周波数で標本化すれば、元の信号を理論上完全に復元できるという定理。これを満たさないと折り返し雑音(エイリアシング)が生じ波形が歪むため、AD変換前にローパスフィルタで高域成分を除去する設計が必要になる。
- 表計算ソフトと関数
- 表計算ソフトは、マス目(セル)に数値や式を入力して集計・分析やグラフ作成を行う日常業務向けのソフト。関数はあらかじめ用意された計算のひな型で、SUM(合計)・AVERAGE(平均)・IF(条件分岐)などを使うと複雑な計算も簡単に記述できる。
- 評価レポート / モデル比較
- 複数モデルやプロンプト構成を共通の指標・データセットで評価し、可視化・自動レポートで比較する仕組み。Bedrock Model Evaluation(自動指標・人手・LLM-as-a-judge)で精度/コスト/レイテンシを横並びにし、選定や改善の意思決定に使う。
- 品質コスト
- 適合コスト(予防コスト・評価コスト)と不適合コスト(内部失敗コスト・外部失敗コスト)の総称。予防・評価に投資するほど失敗コストは下がる傾向にあり、どこに投資すべきかのトレードオフ判断に用いる枠組みとして重要。
- 不正競争防止法(営業秘密)
- 秘密として管理され(秘密管理性)、有用な事業活動情報で(有用性)、公然と知られていない(非公知性)という3要件を満たす「営業秘密」の不正取得・使用・開示を禁止する法律。従業員による顧客リストや技術情報の持ち出し・転職先での使用に対する法的救済の根拠となる。
- 不変(immutable)アクション
- リリース済みアクションのバージョンを書き換え不能にし、参照したバージョンが後から差し替えられないことを保証する仕組み。SHA ピン留めと合わせサプライチェーンの安全性を高める。
- 浮動小数点の誤差(丸め誤差・桁落ち・情報落ち)
- 浮動小数点数は有限の桁数しか持てないため、計算過程でいくつかの誤差が生じる。丸め誤差は表現しきれない下位桁を四捨五入等で切り捨てることで生じる誤差。桁落ちは絶対値がほぼ等しい2数の減算で有効桁数が大きく減る誤差。情報落ちは絶対値が大きく異なる数を加減算した際、小さい方の値が丸められて結果に反映されない誤差。
- 浮動小数点数
- 符号部・指数部・仮数部に分けて実数を表現する形式(IEEE 754が代表的)。広い範囲の数値を扱える一方、10進数の小数を正確に表現できず誤差(丸め誤差)が生じることがある。
- 負荷分散(Load Balancer / Application Gateway / Traffic Manager)
- トラフィックを複数バックエンドへ振り分ける Azure のサービス群。Azure Load Balancer=L4(TCP/UDP)・リージョン内・高速(内部/公開・ヘルスプローブ・バックエンドプール)。Application Gateway=L7(HTTP)・リージョン内・URL パスベースルーティング・SSL 終端・WAF。Front Door=L7・グローバル(エッジ配信・WAF/CDN・リバースプロキシ)。Traffic Manager=DNS ベースのグローバル振り分け(実トラフィックは直接バックエンドへ)。判断軸は「L4 か L7 か」「リージョンかグローバルか」。
- 負荷分散規則
- Load Balancer のフロントエンド IP/ポートで受けた受信トラフィックを、バックエンドプールへヘルスプローブの結果に基づいて分配する規則。既定は 5 タプルのハッシュ分散で、セッションの永続化(送信元 IP アフィニティ)も設定できる。
- 部分インデックス
- WHERE 句で指定した条件を満たす行だけを対象に作るインデックス(例:CREATE INDEX ... ON t (col) WHERE status = 'active')。テーブルの一部にしか使わない検索を軽量・高速にできる反面、条件外の検索には使われない。
- 副問合せ(サブクエリ)
- SQL 文の中に入れ子で記述される別の SELECT 文。1行1列の値を返すものをスカラー副問合せと呼ぶ。EXISTS の否定形である NOT EXISTS のように、副問合せの結果有無を条件に使う書き方もある。
- 複製クエリ(Power Query)
- 既存クエリのステップをすべてコピーして独立した新しいクエリを作る Power Query の機能。複製後は元クエリと切り離され、片方を編集してももう片方には影響しない。参照クエリとは異なり、以後は別々に変化する完全な独立コピー。
- 物理データ独立性
- 内部スキーマ(格納構造・インデックス配置など)を変更しても、概念スキーマに影響を与えずに済む性質。ストレージ方式やインデックスの追加・変更を、上位の論理設計を壊さずに行える。
- 物理的セキュリティ対策(入退室管理・共連れ対策)
- サーバー室やオフィスへの立ち入りを、ICカードや生体認証による入退室管理、施錠、監視カメラの設置などで制限・記録する対策。認証を受けた正規の入室者に続いて未承認者が同時に入り込む共連れ(ピギーバック)は入退室管理だけでは防げないため、一人ずつしか通過できないマントラップ(インターロック式の二重扉)や警備員の目視、入室者本人への意識づけで防ぐ。あわせて、同一IDでの連続入室や出場記録のない再入室を拒否するアンチパスバックにより、カードの貸し借りや共連れの検知に役立てる。
- 分解ツリー(decomposition tree)
- メジャーを次元で段階的に掘り下げて要因を分解する AI ビジュアル。AI が「次に分割すべき次元」も提案する。
- 分岐予測
- パイプライン処理において分岐命令の行き先をあらかじめ予測し、予測が正しければパイプラインの乱れを防いで性能を維持する仕組み。予測が外れるとパイプラインフラッシュが発生し遅延が生じるため、組込みのリアルタイム制御では予測ミスによる実行時間のばらつき(ジッタ)が問題になり得る。
- 分散データベース
- 物理的に離れた複数の拠点にデータを分割・複製して配置しながら、利用者からは単一のデータベースであるかのように扱えるシステム。データの水平分割・垂直分割や複製によって可用性や性能を高める一方、複数拠点間の更新を一貫させる2相コミットなどの制御が必要になる。
- 分散トレースとアプリケーションマップ
- 複数のサービスをまたぐ要求の流れを相関 ID で追跡し、依存関係と遅延をアプリケーションマップで可視化する機能。
- 分散訓練(Reduction Server/Horovod)とハイパーパラメータ調整
- 大規模な訓練を効率化する手段。GPU データ並列の勾配集約(all-reduce)を専用ノードに肩代わりさせる Reduction Server、フレームワーク非依存の Horovod、精度向上のためのハイパーパラメータ調整(Vertex AI Vizier)。アクセラレータはワークロードで選ぶ(大規模 TF/JAX=TPU、汎用=GPU、端末推論=エッジ)。
- 分散型バージョン管理
- 各開発者が履歴の完全なコピーを手元に持つ方式。オフラインでもコミットや履歴閲覧ができる。
- 分散透過性
- 分散データベースにおいて、利用者やアプリケーションがデータの物理的な分散配置を意識せずに単一のデータベースであるかのように扱えること。位置透過性・複製透過性・分割透過性などの種類がある。
- 分析ストア(analytical store)
- コンテナで有効化すると、トランザクションデータが自動で列指向の分析用コピーへ同期される仕組み(HTAP)。Azure Synapse Link で Synapse Spark/SQL から直接クエリでき、運用 RU に影響を与えずに大規模分析ができる。変更イベントを返す変更フィードとは別物。
- 分離レベル(READ COMMITTED/REPEATABLE READ/SERIALIZABLE)
- 同時実行トランザクション間でどこまで他のトランザクションの変更が見えるかを定める設定。標準SQLはREAD UNCOMMITTED(コミット前データも見える=ダーティリードを許容)/READ COMMITTED/REPEATABLE READ/SERIALIZABLEの4段階を定義するが、PostgreSQLはREAD UNCOMMITTEDをREAD COMMITTEDと同一に扱い実質3段階。READ COMMITTED(PostgreSQL の既定)はコミット済みデータのみ見えるが非再現読み取りが起こりうる、REPEATABLE READ はトランザクション開始時点のスナップショットを維持し非再現読み取りだけでなくファントムリードも防ぐ(PostgreSQL固有の挙動)、SERIALIZABLE は直列実行と同等の一貫性を保証する最も厳格なレベル。
- 分類
- 教師あり学習で、カテゴリ(ラベル)を予測する(例:スパムか否か)。
- 文字コードと iconv
- 文字を数値で表す方式。ASCII は英数記号の7ビット基本、Unicode は全世界の文字に番号を割り当てる規格でその代表的符号化が UTF-8(ASCII 互換・Linux 標準)。ISO-8859 は欧州向け、ISO-2022-JP は日本語メールの伝統。iconv -f 元 -t 先 で変換する(文字化けの救出)。
- 文字列関数(char_length/length/lower/upper/substring/replace/trim/`||`/LIKE)
- 文字列を加工・検索する関数と演算子。char_length/length は文字数、lower/upper は大文字小文字変換、substring は部分文字列抽出、replace は置換、trim は前後の空白(または指定文字)除去、連結演算子 || は文字列結合、LIKE 述語はパターンマッチ(% は任意長、_ は任意の1文字。大文字小文字を区別しない ILIKE もある)。
- 平均故障間隔(MTBF)
- 修理して使い続けるシステムで、ある故障から次の故障までの平均稼働時間。値が大きいほど故障しにくく信頼性が高い。総稼働時間÷故障回数で算出する。
- 平均修復時間(MTTR)
- 故障が発生してから復旧するまでの平均時間。値が小さいほど早く復旧でき、保守性(メンテナンス性)が高い。総修復時間÷故障回数で算出する。稼働率=MTBF÷(MTBF+MTTR) の分母に含まれ、MTBF(平均故障間隔)と対にして信頼性・保守性を評価する。
- 平衡木とヒープ
- 平衡木は左右部分木の高さの差を一定範囲に保つことで検索・挿入・削除をO(log n)に保証する2分探索木(AVL木・赤黒木等)。ヒープは親が子より常に大小関係を満たす完全2分木で、優先度付きキュー実装や最大値・最小値の高速取得に用いる。両者とも木構造の均衡性を利用して最悪計算量を抑える点が共通するが、平衡木は順序探索、ヒープは極値抽出に特化する。
- 並行シミュレーション法
- 監査人が独自に作成した検証用プログラムに、本番システムで実際に使用された入力データをそのまま処理させ、その結果を本番システムの実際の出力と照合するCAATの一技法。本番データそのものを用いる点でテストデータ法と異なり、実運用における処理結果の正確性を検証できる。
- 並列化とマルチコア
- 並列化は処理を複数の実行主体に分割し同時実行して高速化する手法全般。マルチコアは1つのCPUチップに複数の演算コアを集積したハードウェア実装で、並列化の主要な基盤となる。並列化効果はアムダールの法則の逐次部分やコア間通信オーバーヘッドで制限される。
- 閉域網
- 通信事業者が提供するインターネットを経由しない専用網(L2の広域イーサネット/L3のIP-VPN 等)で、他契約者のトラフィックと論理的に分離され帯域・遅延の品質保証(SLA)を受けやすい。広域イーサネットやIP-VPN(MPLS等)がその代表的な実現手段である。
- 偏った木
- すべてのノードが片方の子(左または右)のみを持ち、実質的に線形リストと化した2分木のこと。ソート済みデータをそのまま2分探索木に逐次挿入すると発生しやすく、探索・挿入・削除の計算量が本来のO(log n)からO(n)に悪化する。これを防ぐためAVL木や赤黒木のような自己平衡機構が用いられる。
- 変更のリスク評価と切り戻し(バックアウト)
- 変更を実施する前に、その変更がサービスや他の構成品目へ及ぼすリスクと影響を評価し、失敗時に変更前の状態へ確実に戻すための切り戻し(バックアウト)計画を必ず用意しておく統制。切り戻し計画には手順・所要時間・判断基準(いつ中止して戻すか)を含め、実施可能であることを事前に確認する。ITサービスマネージャは切り戻し計画の存在と実効性を変更承認の前提条件とし、稼働中サービスの可用性を守る判断を行う。
- 変更の種別(標準・通常・緊急変更)
- サービスマネジメントにおける変更を承認経路とリスクで分類した3種別。標準変更は事前承認済みの低リスクな定型変更で都度の承認が不要、通常変更はCABがリスク・影響・スケジュールを評価してから承認、緊急変更はサービス停止など切迫した事態に対しECABが迅速に承認し事後に文書化する。ITサービスマネージャは各変更を適切な種別に振り分け、標準変更を増やすことで承認の遅延と評価コストを下げつつ統制を保つ判断が求められる。
- 変更フィード(change feed)
- コンテナの項目の作成/更新を時系列で永続的に読み取れる仕組み(既定で削除は含まない)。Azure Functions トリガー(サーバーレス)か SDK の change feed processor(lease で並列)で処理し、非正規化更新/参照整合/集計永続化/アーカイブをイベント駆動で実装する。
- 変更フィード(Cosmos DB)
- コンテナーへの作成/更新を発生順に読み出せる永続ログ。イベント処理・マテリアライズドビュー・他ストアへの同期に使う(削除は既定で含まない)。
- 変更フィードエスティメーター
- 変更フィードの未処理の変更量(バックログ)を見積もる仕組み。処理が追いついているかを把握し、change feed processor のインスタンス数(並列度)を増減する判断に使う。変更を消費する processor とは役割が異なる。
- 変更管理
- 本番環境への変更を計画・評価・承認・記録し、影響を最小化して安全に反映するための管理プロセス(ITIL の変更管理などが代表例)。承認フロー・変更可能な時間帯の統制・実施後のロールバック手順が中核であり、AWS では SSM Change Calendar や Change Manager がこの一部を自動化するツールとして使われる。
- 変更管理と構成管理(サービスマネジメント)
- ITサービス運用における2つの管理プロセス。変更管理は、システムやサービスへの変更を計画・評価・承認・記録し、変更に伴うリスクや影響を抑えて安全に実施する活動。構成管理は、ハードウェア・ソフトウェア・文書などの構成要素(CI)とその関連情報をCMDB(構成管理データベース)で正確に把握・維持する活動で、変更管理の判断材料にもなる。
- 変更管理統制(プログラム変更管理)
- プログラムやシステム設定の変更について、申請・承認・テスト・本番環境への移行・記録の各段階を統制すること。IT全般統制の中核をなし、無許可の変更や不十分なテストによる障害・不正を防止する。監査人は変更依頼から本番反映までの一連のプロセスに承認と職務分掌が組み込まれているかを検証する。
- 変更追跡(Change Tracking)
- 行が変更されたかどうかを軽量に追跡し、同期や増分処理に使う SQL の機能。履歴値まで保持する変更データキャプチャ(CDC)とは目的が異なる。
- 変数グループと Key Vault 連携
- パイプライン間で共有する設定を変数グループにまとめ、機密値は Azure Key Vault と連携して安全に取得する。セキュアファイルで証明書等を扱う。
- 保管時の暗号化(at rest)
- ディスクやオブジェクトストレージ上に保存されているデータを暗号化すること。クラウドの多くのマネージドストレージ(ブロック/ファイル/オブジェクト/DB)はサービス側の鍵管理(KMSなど)と統合した暗号化オプションを持つ。盗難・不正アクセスからデータ本体を守る基本対策。
- 保護されたアクション(protected actions)
- 最も危険な管理操作(例:Conditional Access ポリシーの削除)に、強い認証コンテキスト(フィッシング耐性 MFA 等)を満たさない限り実行不可とする保護。通常のロール権限より厳格なゲートを追加する。
- 保持ポリシー
- データを必要な期間だけ保持し、不要になれば削除して情報の寿命を管理する仕組み。
- 保持期間(retention)
- ログ・アーティファクト・実行を保持する期間。リポジトリ/組織で設定し、upload 時の retention-days でも調整。REST API で保持ポリシーを管理でき、ストレージ課金に影響する。
- 保証型監査(アシュアランス)
- 監査対象の情報システムや内部統制について、あらかじめ定めた基準に照らして一定の保証(結論や意見)を表明することを目的とする監査の形態。監査人は十分かつ適切な証拠に基づき、対象が基準に適合しているかどうかについて明確な結論を報告する。改善提言そのものが主目的ではない点で助言型監査と異なる。
- 魔の川・死の谷・ダーウィンの海
- 技術経営(MOT)で、基礎研究の成果が事業として成功するまでに直面する3つの障壁を表す比喩。基礎研究から製品開発へ進めるかの関門が「魔の川」、開発した製品化に必要な事業化資金・体制の壁が「死の谷」、市場に出た製品が競合や顧客の受容という淘汰にさらされる段階が「ダーウィンの海」。
- 埋め込み(embeddings)
- テキスト等を数値ベクトルに変換し、意味の近さを比較できるようにする表現。検索やRAGに使う。
- 埋め込みSQL
- C言語やCOBOLなどのホスト言語のソースコード中に直接 SQL 文を記述する方式。コンパイル時にSQL文が確定する静的SQLと、実行時に文字列として組み立てる動的SQLの双方を含みうる。対比されるのは、ライブラリ経由でSQLを渡すコールレベルインタフェース(CLI/ODBC)方式である。
- 埋め込みモデルの選定
- RAG の検索精度を左右する埋め込みモデルの選択。次元数(精度とストレージ/コストのトレードオフ)、ドメイン適合、対応言語、レイテンシで選ぶ。クエリと文書は同じモデルで埋め込み、変更時は全体を再埋め込みする必要がある。
- 未学習(アンダーフィッティング)とバイアス-バリアンス
- 未学習(高バイアス)=訓練・テストとも精度が低い状態で、モデルの複雑化・特徴量追加・学習量増加で対処する。バイアス-バリアンスのトレードオフとは、モデルを複雑にするほどバイアスは下がるがバリアンス(過学習しやすさ)が上がる、という関係を指す。ハイパーパラメータ探索で両者のバランスを取る構成を探す。
- 無線LAN
- 電波を用いてケーブルなしで端末をネットワークに接続する技術(WLAN)。IEEE802.11規格群(b/g/n/ac/ax/be等。11n=Wi-Fi 4、11ac=Wi-Fi 5、11ax=Wi-Fi 6、6GHz拡張=Wi-Fi 6E、11be=Wi-Fi 7)に基づき、アクセスポイントを介したインフラストラクチャモードや端末同士が直接通信するアドホックモードがあり、暗号化にはWPA2/WPA3が用いられる。Wi-FiはWi-Fi Allianceの相互接続認証ブランドで、無線LANの俗称としても使われるが厳密には同義ではない。
- 無線LANのセキュリティ(不正AP対策)
- 無線LANは電波の到達範囲内であれば誰でも通信を傍受・接続を試行できるため、WPA2/WPA3による暗号化・認証、SSIDの適切な管理、MACアドレスフィルタリングなどで保護する。特に、正規のアクセスポイントになりすました不正AP(悪魔の双子・エビルツイン)を設置し、利用者を誤って接続させて通信を盗聴・改ざんする攻撃が脅威となるため、利用者側は接続先の証明書やSSIDの真正性を確認し、組織側は無線LAN監視(WIDS/WIPS)で未承認APの検知・排除を行う。
- 無線LANの周波数帯(2.4/5/6GHz帯)
- 2.4GHz帯は障害物に強く到達距離が長い一方、電子レンジ等との干渉やチャネル数の少なさが弱点。5GHz帯はチャネル数が多く高速だが到達距離が短い。6GHz帯(Wi-Fi 6E/7)はさらに広い連続帯域を持ち、既存機器との干渉が少なく多数の高速チャネルを確保できる。
- 無線LANローミング
- 無線端末が移動しながら、電波が弱くなった接続中のアクセスポイントから、より電波の強い別のAPへ通信を維持したまま接続を切り替える仕組み。成立には複数APに同一SSID・同一認証方式を設定し、同一ネットワークの一部として端末に認識させることが前提となる。
- 無料利用枠(Free Tier)
- 無料で試せる仕組み。2025 年 7 月以降の新規アカウントはサインアップ時にクレジットを付与するプラン型(一定額・利用期間に制限)。従来型は 12 か月無料/常時無料/トライアルの 3 形態。
- 無料利用枠アラート
- 無料利用枠の使用量が上限に近づいたときにメールで警告する AWS Billing の通知。2025-07-15 以降の新規アカウントはクレジット方式の新 Free Tier となり、残クレジットが 50%/25%/10% になった時点や無料期間の残日数(15/7/2日)を通知する。予期しない課金の早期警戒として AWS Budgets と併用されることも多い。
- 名前空間(namespaces)
- Linux カーネルの機能で、プロセスから見える PID・ネットワーク・マウントポイントなどの資源を分離し、あたかも独立した環境にいるように見せる仕組み。cgroups と並ぶコンテナ実現の基盤技術。
- 名前付き値(APIM)
- ポリシーで使う定数や機密を一元管理する仕組み。シークレットは Key Vault と連携して安全に参照する。
- 命名ポリシー(naming policy)
- チーム名/グループ名に接頭辞・接尾辞や禁止語(blocked words)を強制する仕組み。未使用グループを失効させる expiration policy とは別。
- 命令パイプラインハザード
- 命令パイプライン処理において、分岐命令やデータ依存により後続命令が正しく実行できず、パイプラインの乱れ(ストール/フラッシュ)が生じる現象。構造ハザード・データハザード・制御(分岐)ハザードに分類され、組込みではリアルタイム性を乱す要因として、分岐予測や命令並べ替えによる対処が設計上重要になる。
- 命令実行サイクル(フェッチ・デコード・実行・ストア)
- CPUが1つの機械語命令を処理する基本の繰り返し。フェッチ(主記憶から命令を取り出す)→デコード(命令を解読する)→実行(演算・処理を行う)→ストア(結果をレジスタや主記憶に書き戻す)の順に進む。この各段階を複数命令で重ねて並行処理するのがパイプライン処理である。
- 網羅基準と複数条件網羅
- ホワイトボックステストで制御構造をどこまで通したかを測る基準。命令網羅(全命令を1回以上実行)⊂分岐(判定)網羅(各分岐のtrue/falseを網羅)と厳しくなるが、条件網羅(各条件のtrue/falseを網羅)は分岐網羅を必ずしも包含しない。複数条件網羅は判定文中の全条件の真偽の全組合せを網羅する最も厳しい基準で、分岐網羅・条件網羅を包含する。テストの十分性を定量的に示す。
- 木構造(ツリー)
- データを親子の階層関係で表すデータ構造。頂点(根)から枝分かれして下位の要素(節・葉)へつながる形をとり、フォルダの階層や組織図のように、階層的なデータの表現に適している。
- 木構造と2分探索木
- 節(ノード)と枝(エッジ)から成る階層的なデータ構造。2分探索木は各節の左部分木が親より小さい値、右部分木が大きい値になるよう構成され、探索・挿入・削除を平均O(log n)で行える。
- 問題管理
- 一つ以上のインシデントの根本原因(問題)を特定し、恒久的な対策と再発防止を図るプロセス。すでに発生したインシデントに反応するリアクティブと、傾向分析などで未然に防ぐプロアクティブの両面をもつ。迅速な回復を狙うインシデント管理とは目的が異なり、原因除去に主眼を置く。
- 優先制御方式(厳格優先/WFQ)
- 厳格優先(PQ: Priority Queuing)は高優先度キューに常に先着で送出権を与え、そのキューが空になるまで低優先度キューを処理しない方式で、高優先トラフィックの遅延・ジッタを最小化できる反面、高優先が輻輳すると低優先が飢餓(スタベーション)に陥る。WFQ(Weighted Fair Queuing)は各キューに重みに応じた帯域比率を保証しつつ複数キューを交互に処理する方式で、飢餓を防ぎつつ相対的な優先度差を実現する。
- 優先度逆転
- 高優先度タスクが、低優先度タスクが保持する共有リソースのロック解放を待つ間に、中間優先度のタスクに実行権を奪われ続け、結果として高優先度タスクの実行が事実上、中優先度タスクより後回しになる現象。デッドラインを外す重大な不具合原因となり、優先度継承や優先度上限プロトコルによる対処が必要。
- 優先度継承プロトコル/優先度上限プロトコル
- 優先度逆転への2つの対処法。優先度継承プロトコルは、高優先度タスクが待っているロックを保持する低優先度タスクの優先度を一時的に待機側と同じ水準まで引き上げ、中間優先度タスクに横取りされないようにする。優先度上限(天井)プロトコルは、各共有リソースにそれを使用しうる全タスク中の最高優先度をあらかじめ設定し、ロック取得時に直ちにその上限まで引き上げる方式で、より単純な実装でデッドロック防止も同時に実現できる。
- 有効期限ポリシー(expiration policy)
- 未使用の Microsoft 365 グループ(チーム)を一定期間後に自動で失効させ整理する仕組み。命名を強制する naming policy とは別。
- 予測(forecasting・Power BI)
- 時系列データから将来値を推定する分析機能。参照線(基準線)とは別で、時系列が前提。異常検出と併せて使うことが多い。
- 予測型/適応型ライフサイクル
- 予測型(ウォーターフォール型)はスコープ・スケジュール・コストを早期に確定し順に進める方式、適応型(アジャイル型)は要求の変化を前提に反復・漸進的に進める方式。要件の確実性や変化の速さに応じてどちらのライフサイクルを選ぶべきかを判断する分岐点として重要。
- 予防優先とゲートベース
- 予防優先は源流で問題を混入させない戦略(Push Protection 等)。ゲートベースはマージ/デプロイ前の必須チェックで脆弱なものを通過させない戦略(Code Scanning/Dependency Review 必須化)。排他ではなく多層で併用する。
- 容量(capacity)
- Dataverse のデータベース/ファイル/ログ容量や API 要求数など、ライセンスに紐づく利用可能なリソース量。管理センターで監視・配分する。
- 容量(Fabric キャパシティ)
- Fabric のコンピュートと課金の単位。F SKU(や Power BI Premium の P SKU)で購入し、容量ユニット(CU)を消費する。一時停止/再開でき、ワークスペースを紐づけて使う。
- 容量メトリックアプリ
- 容量ユニット(CU)の消費やスロットリングを可視化し、過負荷の原因アイテムを特定するための管理用アプリ。
- 要求実現(サービス要求)
- 計画外の中断ではなく、あらかじめ手順・承認・コストが定められた定型的な利用者要求(アカウント発行、標準ソフトウェアの導入、情報提供など)を処理するプロセス。障害対応であるインシデント管理や、変更管理を要する非定型の変更とは区別して扱う。
- 要件定義
- システム開発の上流工程で、利用者・発注者が求める機能や性能を明確にし、開発対象の範囲を確定する工程。ここでの認識齟齬は後工程の手戻りに直結するため特に重要。
- 要配慮個人情報
- 個人情報保護法上、人種・信条・病歴・犯罪歴など、本人に対する不当な差別や偏見が生じないよう特に慎重な取り扱いを要する個人情報の区分。取得には原則として本人の同意が必要で、通常の個人情報より厳格な保護が求められる。
- 要約(抽出/抽象)
- 長文や会話の要点をまとめる機能。抽出的要約は重要文を選び、抽象的要約は新しい文で言い換えて要約する。
- 利用パターン(採用・未活用機能)
- 機能の採用状況・アクティビティ・未活用機能を評価し、教育・展開やコスト見直しにつなげる分析の観点。
- 利用規約(Terms of Use, ToU)
- アクセス付与の条件としてユーザーに同意を求める規約。Conditional Access やエンタイトルメント管理と連携し、規約に同意しないとアクセスできないよう設計できる。
- 流れ図(フローチャート)
- 処理の手順や流れを、決められた図記号(端子・処理・判断・線)を使って順序立てて表した図。プログラムや業務の流れを視覚的に整理でき、分岐や繰り返しの構造を分かりやすく示せる。
- 粒度(グレイン)
- ファクトテーブルの 1 行が表す詳細さの単位(例:1 取引・1 日 1 製品)。設計の最初に決め、これが集計の正しさを左右する。
- 両利きの経営
- 既存事業の深化(Exploitation=効率化・磨き込みによる収益確保)と、新規事業の探索(Exploration=不確実な新領域への挑戦)という、性質の異なる2つの活動を組織内で両立させる経営のあり方。ストラテジストは、深化に偏ると環境変化への対応力を失い(イノベーションのジレンマ)、探索に偏ると収益基盤を失うという相反関係を踏まえ、両者を同じ組織内で共存させるか、別組織に分離して経営陣がバランスを取るかを設計する。
- 料金モデル(オンデマンド/Savings Plans・RI/スポット)
- オンデマンド=従量・最も柔軟、Savings Plans/RI=1〜3年コミットで割引、スポット=余剰容量を最大約90%引き(中断あり)。
- 倫理規範
- セキュリティ専門家が業務で得た情報や権限を悪用せず、法令や組織の方針に従って責任を持って行動するための行動規範。侵入テスト等の攻撃的な技術を扱う職務ほど、許可の範囲を超えないという倫理的な線引きが重要になる。
- 隣接関係(OSPFアジャセンシー)
- 2台のOSPFルータがLSAを交換し合い、互いのリンクステートデータベースを完全に同期させた状態(Fullステート)。Hello交換だけで留まる隣接(2-Wayステート止まり)とは異なり、アジャセンシーが確立した相手同士のみが経路情報を実際に交換する。ルータID重複・Hello/Deadタイマー不一致・エリア番号不一致などが確立を妨げる典型的な原因となる。
- 列(Dataverse)
- テーブルの各フィールド。テキスト・数値・日付・選択肢・参照などの型を持ち、入力ルールや必須を設定できる。旧称フィールド。
- 列レベルセキュリティ(Fabric)
- 特定の列を利用者から隠すデータ単位のセキュリティ。ウェアハウスや SQL 分析エンドポイントで GRANT/DENY により列単位のアクセスを絞り、行レベルセキュリティ(RLS)とは制御軸が異なる(行 vs 列)。両者は併用できる。
- 列指向フォーマット(Parquet/ORC)
- 列単位で格納する分析向けフォーマット。必要列だけを読みスキャン量と I/O を削減し、圧縮効率も高い。Athena/Spark のコストを大きく下げる。
- 連関エンティティ
- E-R図で多対多の関連を解消するために導入する、両エンティティの主キーを外部キーとして持つ中間実体。関連自体が持つ属性(例:受注日)も持てるようにし、関係データベースの表として実装しやすくする。
- 連絡先(Microsoft 365 contact)
- サインインできない、メール送信のみを目的としたディレクトリ オブジェクト。組織の Exchange Online アドレス帳や配布リストに外部の相手先を表示させたいが、テナントへのアクセス権は与えたくない場合に使う(ゲストユーザーとの主な違い)。ライセンスも Entra ID のサインインも不要。
- 労働者派遣法
- 派遣元事業主が労働者を派遣先企業へ派遣して働かせる際のルールを定める法律。指揮命令は派遣先が行うが、雇用契約は派遣元との間にある点が請負契約との違い。
- 論理データ独立性
- 概念スキーマ(テーブル構造など)を変更しても、外部スキーマ(アプリケーションが見る形)に影響を与えずに済む性質。3層スキーマの狙いの一つで、テーブル追加やカラム再編がアプリ改修を伴わずに行える。
- 論理バックアップ・リストア(pg_dump/pg_dumpall/pg_restore)
- SQL レベルバックアップのツール群。pg_dump は単一データベースを論理バックアップし、pg_dumpall はロールやテーブル空間を含むクラスタ全体をダンプする。pg_restore はカスタム/ディレクトリ/tar 形式の pg_dump 出力からリストアし、-t オプションで特定テーブルのみを対象にできる。
- 論理演算(AND・OR・NOT・XOR)
- 真(1)・偽(0)の2値を扱う演算。ANDは両方とも真のときのみ真、ORはどちらか一方でも真なら真、NOTは真偽を反転、XOR(排他的論理和)は入力が異なるときのみ真になる。
- 論理回路
- AND(論理積)・OR(論理和)・NOT(否定)などの論理ゲートを組み合わせ、2進数の0/1で表される信号に対して論理演算を行うデジタル回路。出力が現在の入力だけで決まる組合せ回路と、フリップフロップなどの記憶素子を持ち過去の状態にも依存する順序回路に大別される。コンピュータの演算・制御回路の基礎をなす。
- 冪等性キーパターン
- クライアントがリクエストごとに一意なキーを付与し、サーバー側がそのキーの処理結果をキャッシュして同一キーの再送を重複実行させないようにする設計パターン。ネットワーク再試行やSQSの最低1回配信で同じ処理が複数回走る問題(決済の二重処理等)を防ぐ。DynamoDBの条件付き書き込みでキーの初回性を判定する実装が一般的。
- 輻輳制御
- ネットワークやルータの処理能力を超えるトラフィック流入(輻輳)を検知し、送信レートを調整して破綻を防ぐ仕組み。TCPのスロースタート・輻輳回避・高速再送/高速リカバリや、ルータ側のRED(Random Early Detection、キュー満杯前に確率的に早期廃棄しTCPの輻輳回避を誘発する方式)が代表例。エンド間(TCP)とネットワーク内(RED等のAQM)の両輪で機能する。

