2026 年 5 月 26 日、Publickey が Docker 専用の AI エージェント「Gordon」が正式リリース。Docker について何でも答えてくれてエラーも修正してくれる。無料アカウントでも利用可能 を報じました。Gordon は Docker Inc. が公式に提供する Docker 特化型 AI エージェントで、Dockerfile の最適化 / Compose 設定の自動補完 / コンテナ起動エラーの解析 / イメージサイズ削減提案 / セキュリティ脆弱性の検知までを Docker CLI / Docker Desktop / Web UI から自然言語で操作できます。無料 Docker Hub アカウントでも利用可能で、法人プランでは利用ログ / SSO / アクセス制御が追加されます。
受託で中堅企業の コンテナ基盤 / 内製ヘルプデスクを支える立場では、これは 「Docker トラブルが SRE / インフラ担当に集中し続けてきた業務」を 「現場エンジニアが自己解決し、SRE は本来の改善業務に集中する」構造に変える受託機会を意味します。これまで Grab マルチエージェント社内ヘルプデスク受託 で扱った 社内エンジニアリングサポート、Deno 2.8 ランタイム移行受託 で扱った ランタイム選定統治、Cloudflare 6 層エージェント基盤受託 で扱った エージェント運用基盤と接続して、Docker 特化 AI を「組織のコンテナ運用文化」に組み込む設計を受託します。
なぜ「Docker 特化 AI が分水嶺」なのか
| 観点 | 既存 ChatGPT / Copilot による Docker 対応 | Docker Gordon |
|---|---|---|
| コンテキスト精度 | 一般知識 / 古い情報混入 | Docker 公式 / 最新仕様準拠 |
| エラーの解析範囲 | コピペで貼り付け解析 | コンテナ / ログ / 設定を直接読込 |
| 環境差異の吸収 | 手動説明が必要 | Docker Desktop と統合 |
| セキュリティ統制 | 社外 LLM に機密設定流出リスク | 法人プランで SSO / DLP |
| 対応領域 | Dockerfile / Compose 中心 | + Buildx / Swarm / BuildKit / Hub |
| 修正提案の信頼度 | 50〜70%（実行検証なし） | 80〜90%（公式知識ベース） |
| 学習効率 | 担当者の調査時間で吸収 | 対話履歴が組織知化 |
| ライセンス / 価格 | 別途 LLM 契約必要 | Docker Hub 無料枠から利用可 |
つまり Docker Gordon は **「汎用 LLM では届かなかったコンテナ運用の最後の 1 マイル」を埋めるツールであり、「Docker トラブルを担当者個人の経験値で解決する文化」から 「組織でナレッジ化される自助文化」**へ転換します。
受託案件で活きる 3 つの構造変化
構造 1: 「Docker トラブル＝ SRE 召喚」から「現場で自己解決」へ
中堅企業の 開発者 30〜100 名規模では、「コンテナ起動しない」「ローカルだけで再現する」「Compose のネットワークが繋がらない」といった Docker トラブルが日次で発生し、SRE / インフラ担当の時間を奪い続けるのが定常です。Gordon を 公式の自己解決窓口として組織導入すると、1 次切り分けが現場で完結し、SRE は本質的なプラットフォーム改善に時間を投下できます。これは Grab マルチエージェント社内ヘルプデスク受託 で扱った AI による 1 次対応と同じ思想の、Docker レイヤ版です。
構造 2: 「個人の Docker 経験値」から「組織のコンテナ運用ナレッジ」へ
Gordon の対話履歴は 「組織内でどの Docker トラブルがどう解決されたか」の 一次データとなり、ポストモーテム / オンボーディング / 設計判断の素材になります。受託案件では 対話ログを Confluence / Notion / GitHub Wiki にエクスポートし、社内 RAGの知識源にする設計まで含めます。
構造 3: 「コンテナセキュリティが後付け」から「常時診断」へ
Gordon は Dockerfile / Compose / Image の 脆弱性 / ベストプラクティス逸脱を 常時診断します。これにより AI コーディングエージェント設定攻撃面受託 で扱った 設定ファイルレベルのハードニングを、ビルド前 / マージ前の 最も上流で実施可能になります。
受託で提供する「Docker Gordon 組織導入」5 フェーズ
フェーズ 1: 現状診断（2 週間）
- Docker 利用実態調査（開発者 / SRE / CI/CD / 本番）
- コンテナトラブル発生件数 / 平均解決時間ベンチマーク
- SRE 対応の比率分析（割り込み件数 / 工数）
- 既存 Dockerfile / Compose 品質スコアリング
- Gordon 適用優先プロジェクト決定
フェーズ 2: アカウント設計とアクセス制御（2 週間）
- Docker Business / Team プラン契約方針
- SSO（Okta / Azure AD / Google Workspace）統合
- IP 制限 / 監査ログ要件整理
- データ送信ポリシー（機密設定の Gordon 共有可否）
- 利用者ロール定義（開発者 / SRE / 経営閲覧）
フェーズ 3: パイプライン統合（3〜4 週間）
- Docker Desktop 配布 + Gordon 有効化
- CI/CD（GitHub Actions / GitLab CI）からの Gordon 呼出し
- pre-commit / Husky で Dockerfile Lint + Gordon 提案表示
- イメージビルド時の脆弱性自動レビュー
- Slack / Teams への通知連携
フェーズ 4: ナレッジ運用設計（3〜4 週間）
- 対話ログのエクスポート / 匿名化
- 月次レビュー会議体（SRE + 開発代表）
- ポストモーテム / オンボーディングへの組み込み
- 社内 RAG（Confluence / Notion）への取り込み
- ベストプラクティス Wiki 更新フロー
フェーズ 5: 月次運用レビュー（継続）
- Gordon 利用率 / トラブル解決時間
- SRE 割り込み件数の推移
- Dockerfile / Compose 品質スコア
- セキュリティ警告対応 SLA
- 新規プロジェクトへの展開計画
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| AI エージェント | Docker Gordon（Business / Team） | Claude Code / Copilot Workspace |
| コンテナランタイム | Docker Desktop / Docker Engine | Podman / containerd |
| CI/CD 統合 | GitHub Actions / GitLab CI | CircleCI / Jenkins |
| SSO / IdP | Okta / Azure AD / Google Workspace | Auth0 |
| イメージレジストリ | Docker Hub / GHCR / Artifact Registry | ECR / Harbor |
| 脆弱性スキャン | Docker Scout / Trivy / Snyk | Anchore |
| ナレッジ基盤 | Notion / Confluence / GitHub Wiki | esa / DocBase |
| 可観測性 | Datadog / Grafana / Honeycomb | New Relic |
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| 開発者 30 名以上で Docker を日常利用 | 単一プロジェクト / 個人開発 |
| SRE 割り込み対応が業務逼迫している | 専任 SRE が十分にいる大企業 |
| Dockerfile 品質がプロジェクト間でばらつく | 標準化済みのワンチーム |
| マイクロサービス / コンテナ多数運用 | モノリス + VM 中心 |
| オンボーディング期間を短縮したい | 入社者が年 1〜2 名 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| データ送信範囲 | Gordon に送る Dockerfile / ログ / コマンド | 機密度 / 個人情報除外 |
| 対象プロジェクト範囲 | 開発 / ステージング / 本番 | 段階導入の境界 |
| SLA / 障害時運用 | Gordon ダウン時の代替手順 | 業務継続計画 |
| 監査ログ保持 | 期間 + アクセス制御 | 法令要件 |
| 退場時引き渡し | ナレッジ / 設定 / 運用手順書 | 自社運用継続性 |
| モデル更新ポリシー | Gordon バージョン変更の検証 | 業務影響評価 |
価格モデル — Docker Gordon 組織導入パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 / PoC | 130 万円〜（5 週間） | 棚卸し + 1 プロジェクト PoC | レポート + ロードマップ |
| Lite | 45 万円〜 / 月 | 開発者 30〜50 名 | 月次レビュー + Q&A 支援 |
| Standard | 95 万円〜 / 月 | 開発者 50〜150 名 | + CI/CD 統合 + 脆弱性運用 |
| Enterprise | 200 万円〜 / 月 | 開発者 150 名超 | + 専任エンジニア + 月次ワークショップ |
| 初期構築 | 320 万円〜（一括） | SSO + CI/CD + ナレッジ基盤 | 全プラン共通オプション |
顧客側 ROI 試算（開発者 80 名 / SRE 4 名 / 月次トラブル 60 件想定）
| 項目 | 既存（SRE 個別対応） | Gordon 導入後 | 差分 |
|---|---|---|---|
| Docker トラブル平均解決時間 | 90 分 | 25 分 | -65 分 / 件 |
| SRE 割り込み工数（月） | 90 時間 | 24 時間 | -66 時間 / 月 |
| Dockerfile 品質改善（年） | 場当たり | 常時診断で改善 | 脆弱性 -70% |
| 新人 Docker 習熟期間 | 3 ヶ月 | 1 ヶ月 | -2 ヶ月 |
| インシデント起因のロールバック | 月 2 件 | 月 0〜1 件 | -12〜18 件 / 年 |
| 年間効果 | — | — | 約 1,250 万円相当 + SRE の本質業務復帰 |
時給 8,000 円換算で 年間 1,000 万円超の工数削減。Standard プラン（年額 1,140 万円）でも 12 ヶ月以内で回収可能です。
ハマりやすい 5 つの落とし穴
落とし穴 1: 「Gordon に全部聞けば良い」と現場が放任
Gordon の提案を 検証せずに本番反映する文化が広がると、誤提案 → 本番障害の事故化リスクが高まります。Gordon 提案は PR レビュー必須を契約条項に書きます。
落とし穴 2: 機密情報を Gordon に送りすぎる
Dockerfile に API キー / 接続情報 / 顧客名が混入したまま Gordon に送信され、ログに残る事故が発生します。Gordon 送信前の自動マスキングを CI に組み込みます。
落とし穴 3: SRE が「自分の仕事がなくなる」と抵抗
導入初期に SRE が Gordon を敵視すると、ナレッジ提供が滞り、品質が上がりません。SRE を「Gordon 教育係」として位置付け、評価項目に組み込みます。
落とし穴 4: 無料プランのまま組織導入
Docker Hub 無料アカウントのまま組織展開すると、SSO / 監査ログ / IP 制限がなく、情シスから NGが出ます。最初から Business / Team プランで設計します。
落とし穴 5: ナレッジ化を後回し
「Gordon に聞けば毎回答えてくれる」と 対話ログを蓄積しないと、組織知が育たないまま運用が続きます。月次でログを要約 → Wiki 化するフローを必須化します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | Docker 利用実態 + SRE 割り込み調査 |
| Week 3〜4 | プラン契約 + SSO 統合 + ポリシー策定 |
| Week 5〜7 | 1 プロジェクト PoC + Gordon 配布 |
| Week 8〜9 | CI/CD 統合 + 脆弱性運用フロー |
| Week 10 | 全社展開（Slack 通知 + オンボーディング） |
| Week 11 | ナレッジ化フロー稼働 + 月次レビュー初回 |
| Week 12〜13 | KPI 計測 + 改善サイクル定着 |
まとめ — 「Docker 特化 AI」が SRE を本質業務に戻す
Docker Gordon の GA は、「コンテナ運用が SRE の暗黙知に依存する文化」を 「組織で自助解決できる文化」へ転換する分水嶺です。受託で中堅企業の 開発生産性 / コンテナ統制を支える立場では、Gordon 導入 + SSO + CI/CD + ナレッジ化を一体で提供する 「コンテナ運用ヘルプデスク AI」が新しい主力サービスになります。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で本パッケージを提供しています。「Docker トラブルが SRE を逼迫」「Dockerfile 品質がバラバラ」「コンテナ脆弱性運用が回らない」というご相談は お問い合わせフォーム からお気軽にどうぞ。
