付録D：更新方針と更新履歴
本書は、特定モデル、特定ツール、価格、UI、APIの細部に依存しすぎないように維持します。本文には長く使う判断原則、責任境界、検証方法、統制観点を残し、変化しやすい情報には確認日、対象バージョン、正本、適用範囲を添えます。
この付録は読者向けです。読者が「記述はいつ、何を根拠に確認され、現在の自分の条件にも適用できるか」を判断する方法と、内容上の主な変更を示します。公開・検証作業を行う保守者向けの手順は、リポジトリ直下の MAINTENANCE.md へ分離しています。読者がその手順を実行する必要はありません。
D.1 本文に残す情報 / 更新時に確認する情報
| 区分 | 本文に残す | 更新時に確認する |
|---|---|---|
| モデル / ベンダー | 選定時に見る判断軸、exit strategy、vendor portability | モデル名、料金、ベンチマーク値、UI手順、契約条件 |
| API / ツール | approval、audit、rollback、least privilege、isolationの原則 | APIの引数、画面操作、SDK固有の実装、breaking change |
| 評価 | eval plan、acceptance criteria、regression、trace-based evaluationの考え方 | 評価データセット、実測値、製品固有dashboard |
| セキュリティ | データ分類、権限、監査ログ、threat model、インシデント対応 | 個別製品の設定画面、ポリシー、設定手順 |
| 運用 | fallback、manual takeover、kill switch、postmortem、trainingの構造 | 監視サービスの設定項目、アラート名、通知先 |
| 組織 / 契約 | decision rights、risk acceptance、buy / build / partnerの判断軸 | 契約条項、価格表、利用規約の変更 |
本文に固有名がある場合は、固有名だけで結論を受け入れず、対応する一般概念と公式情報を確認します。固有情報が変わっても一般原則が変わらないなら、判断原則はそのまま利用できます。
D.2 変化の速い論点の確認方法
| 論点 | 本文で確認する原則 | 正本として確認する情報 | 再確認のきっかけ |
|---|---|---|---|
| モデル名 / provider | 品質劣化時の判断、outage対応、exit strategy | 公式ドキュメント、利用規約、変更履歴 | モデル廃止、名称変更、契約変更 |
| 価格 / quota / rate limit | cost budget、cost anomaly、TCO、上限設定 | 公式料金、契約見積、利用量dashboard | 料金改定、上限到達、利用量の急変 |
| UI / 画面手順 | 誰が承認し、何を監査ログへ残すか | 公式手順、対象バージョン、取得日付き画面 | UI変更、権限モデル変更 |
| API / SDK / connector | schema、validation、approval、audit、rollback | 公式API reference、SDK version、breaking change note | major update、廃止予告、認証方式変更 |
| セキュリティ分類 | data classification、least privilege、incident response | 適用する規程、法令、監査要件 | 規程改定、対象データ変更、例外申請 |
| eval / benchmark | acceptance criteria、失敗例、regression、評価手順 | dataset version、測定期間、計算式、実行記録 | dataset変更、品質回帰、測定条件変更 |
外部情報が本文と食い違う場合は、確認日が新しいだけで正しいと決めません。対象バージョン、契約、地域、権限、測定条件が同じかを確認し、違いがあれば適用範囲を分けます。
D.3 鮮度情報の読み方
変化しやすい記述は、可能な範囲で次の5項目を組にします。
| 項目 | 読者が確認すること |
|---|---|
| 確認日 | その情報を最後に確認した日。公開日や執筆日と同じとは限らない |
| 対象バージョン | 製品、規格、API、SDK、契約など、確認対象を識別できる版 |
| 正本 | ベンダー、標準化団体、法令提供元などが公開する一次情報 |
| 適用範囲 | 地域、プラン、環境、権限、組織規程など、その説明が成立する条件 |
| 再確認条件 | 日付だけでなく、廃止予告、料金改定、障害、規程改定などの早期trigger |
記録例（架空）
次は記載形式を示す架空例であり、実在するAPIの仕様ではありません。
| 項目 | 記録例 |
|---|---|
| 確認日 | 2026年7月1日 |
| 対象バージョン | 架空の Example API v3.2 |
| 正本 | 提供元が公開するAPI referenceと変更履歴 |
| 適用範囲 | Enterprise契約、東京リージョン、管理者権限での設定 |
| 再確認条件 | major versionの更新、認証方式の変更、廃止予告の公開時 |
この形式なら、日付だけでなく「何を」「どの条件で」確認したかが分かります。たとえば契約プランが異なる読者は、同じAPI versionでも自分の条件へそのまま適用せず、正本で差異を確認できます。
読者は次の順序で鮮度を確認できます。
- 対象ページに確認日と適用範囲があるか確認する。
- 正本を開き、対象バージョンと現在利用している条件を照合する。
- 再確認条件が発生していないか、正本の変更履歴を確認する。
- 5項目が不足する場合、その固有情報を確定事項ではなく再確認が必要な情報として扱う。
- 差異やリンク切れを見つけた場合は、任意で、該当ページ、確認した正本、確認日、差異を添えて改善提案を送る。GitHubを利用しない場合は
knowledge@itdo.jpへ連絡する。
D.4 陳腐化の兆候と読み替え
| 節の種類 | 陳腐化の兆候 | 読者の対応 |
|---|---|---|
| モデル / providerの説明 | 固有名が判断原則より目立つ、価格や制限が現在と違う | 固有情報を正本で再確認し、選定軸とexit strategyを利用する |
| API / UI手順 | 画面名、ボタン名、引数名が一致しない | 操作を推測せず、approval、audit、rollbackの責任境界へ戻る |
| セキュリティ対策 | 製品設定だけで説明し、対象データや脅威が違う | threat model、data classification、least privilegeから再評価する |
| eval / benchmark | 単一スコアだけで母数、期間、計算式がない | 自組織のacceptance criteriaと測定条件へ置き換える |
| 事例 / ケース | 成功例だけで、失敗時挙動や適用条件がない | 実証済みの一般値とみなさず、検証用のモデルケースとして扱う |
| 組織運用 | 役割名だけでdecision rightsがない | owner、approver、escalation、risk acceptanceを自組織で定義する |
固有情報に確認日や正本がなく、現在の条件とも一致しない場合は、その値や手順をそのまま採用しないでください。判断原則を使い、現在の一次情報と組織条件から再評価します。
D.5 更新履歴
2026年7月20日
- 公開本文から内部の作業番号と検証証跡を分離し、この付録を読者向けの鮮度確認手順と更新履歴へ再構成しました。
- 変化しやすい情報について、確認日、対象バージョン、正本、適用範囲、再確認条件の読み方を明示しました。
- 保守者向けの公開・検証手順はリポジトリ直下の専用runbookへ移しました。
2026年5月24日
- 全6章を、AIネイティブな意思決定、要求境界、設計判断、delivery、合意形成、インシデント対応の構成へ更新しました。
- 付録Aを実務成果物テンプレート集、付録Bを3つのモデルケース、付録Cを公式情報と関連書籍を含む推奨読書リストへ再構成しました。
- モデル、価格、UI、APIなど変化しやすい情報を一般原則から切り分ける方針を追加しました。
- AI協働の標準手順、判断責任の3層モデル、レビュー項目を接続しました。
1.0.0（2026年1月19日）
- AI協働の標準手順と前作への接続を追加しました。
- LLM / 生成AIアプリケーションの設計論点、成果物テンプレート、ケーススタディ、ライセンスFAQを拡充しました。
D.6 保守者向け情報との境界
この公開付録が扱うのは、読者が内容の鮮度と適用範囲を判断するための情報です。変更単位、レビュー、CI、公開確認、証跡記録などを再現する責務は保守者が担い、リポジトリ直下の MAINTENANCE.md で管理します。
読者向けページには、作業管理番号や個別の検証ログではなく、内容上の変更、確認日、正本、適用範囲を残します。これにより、リポジトリの運用履歴を知らない読者も、この付録だけで再確認の要否を判断できます。