ほとんどの開発チームが抱えるインフラギャップ
専任のDevOpsエンジニアがいない開発チームには一貫したパターンがあります。アプリケーションはうまく構築されているのに、デプロイがうまくいかないのです。コードはクリーンでテストされ、レビューもされています。Dockerの設定は別のスタック向けに書かれたチュートリアルを無理やり流用しています。CI/CDパイプラインは存在しないか、不安定に動作しているか、2週間も壊れたままで誰も修正する時間がありません。インフラは手動でプロビジョニングされ、ドキュメントもなく、本番環境が故障した場合は復旧に数日かかるでしょう。
このような状況下でのデプロイは常にリスクを伴います。ピークトラフィック時のデプロイ失敗はダウンタイムを引き起こします。インフラのセキュリティ設定ミスは、適切に構成されたパイプラインならデプロイ前に検出できる脆弱性をアプリケーションにさらします。ヘルスチェックがないと、壊れたコンテナにトラフィックが送り続けられます。これらは決して難しい問題ではありませんが、チームにDevOpsの知識がなく、習得する時間もないために解決できていないのです。
KissMySkillsのDevOps agentであるRupertは、このギャップを体系的に埋めます。技術スタック、クラウドプロバイダー、デプロイ要件、既存のセットアップについて的確な質問を行い、テンプレートではなく、すぐにリポジトリにコミットできるテスト済みの本番対応の設定ファイルを生成します。
DevOps構成に実際に必要なこと
DevOpsをあまり経験していない開発者は、適切に構成されたデプロイ環境に必要な範囲を過小評価しがちです。典型的なウェブアプリケーションの本番環境セットアップには、コンテナ化（マルチステージビルドを用いたDockerfile、ローカル開発用のdocker-compose、イメージサイズを抑えるための.dockerignore）、CI/CDパイプライン（ブランチイベントでトリガーされる自動リント、テスト、ビルド、デプロイジョブ、環境ごとの設定とシークレット管理）、インフラストラクチャ・アズ・コード（Terraformなどでクラウドリソースをバージョン管理された設定ファイルで定義し、手動コンソール操作を排除）、監視とアラート設定、全レイヤーにわたるセキュリティ設定が含まれます。
ほとんどの開発チームはこれらの断片を持っていますが、Dockerfileが動く、部分的なCI/CDパイプライン、手動でプロビジョニングされたインフラなどにとどまっています。Rupertはこれらのギャップを埋め、使用中のスタックとプラットフォームに合わせた完全な本番対応版を提供します。
Rupertが各構成タイプで生成するもの
Dockerとコンテナ化。 マルチステージビルド（ビルドステージとランタイムステージを分離し最終イメージサイズを最小化）、非rootユーザー設定（多くの開発者が省略しがちなセキュリティ要件）、ヘルスチェック定義、.dockerignoreファイルを備えた本番対応Dockerfile。ローカル開発・テスト用のdocker-composeファイル。すべての非自明な決定に対するインラインコメント。ローカルで設定を検証するためのビルド・テストコマンド。
CI/CDパイプライン。 GitHub ActionsまたはGitLab CIの完全なYAMLファイル。リントと静的解析、単体・統合テスト、セキュリティスキャン、イメージビルドとレジストリへのプッシュ、ターゲット環境へのデプロイをカバー。ステージングと本番の環境別設定、プラットフォーム固有のシークレット管理手順。条件付きデプロイロジック（PRマージ時にステージングへ、リリースタグ時に本番へ）、ロールバック設定。
インフラストラクチャ・アズ・コード。 標準レイアウト（main.tf、variables.tf、outputs.tf）で構成されたTerraformモジュール。チーム利用のためのリモートステート設定、環境別変数ファイル。AWS、GCP、Azureのいずれか、チームが使用するクラウドに合わせて、アプリケーションタイプに適したリソース種別と設定。誤ってインフラを削除しないためのdestroyプランレビュー手順。
Kubernetesマニフェスト。 コンテナ化アプリケーション向けのDeployment、Service、ConfigMap、Ingressリソース。共有クラスタでのメモリ・CPU問題を防ぐためのリソース制限とリクエスト。LivenessおよびReadinessプローブ設定。トラフィック変動に対応する水平Podオートスケーラー設定。
後付けではなく組み込まれたセキュリティ
インフラ構成におけるセキュリティは別のフェーズではなく、初期セットアップ時に行う一連の決定であり、脆弱性を生むか防ぐかを左右します。最も省略されやすく、悪用されやすい決定は予測可能です。設定ファイルにハードコードされたシークレット、過剰な権限を持つIAMロール、rootで動作するコンテナイメージ、必要以上に広いネットワーク公開、CIパイプラインでのイメージスキャンの欠如などです。
Rupertの出力には必ずSecurity Notesセクションが含まれ、構成ごとのセキュリティ考慮点を説明します。リポジトリにコミットせずシークレット管理に保存すべき値、デプロイロールに必要な最小限のIAM権限、制限すべきネットワークポート、使用中のCIプラットフォームに推奨されるイメージスキャン統合などです。これらは開発チームが時間的制約の中で最も後回しにしがちであり、本番環境で最も重大なセキュリティインシデントを引き起こす要因です。
汎用テンプレートではなくプラットフォーム固有の構成
汎用的なDevOpsテンプレートは出発点に過ぎず、特定環境で動作させるには大幅な適応が必要です。Node.jsアプリをAWS ECSにデプロイする場合とGoogle Cloud Runにデプロイする場合では、TerraformもCI/CD設定もヘルスチェック設定も異なります。GitHub ActionsはGitLab CIと異なる構文、トリガー機構、シークレット管理を持ちます。AWSのIAMロール設定はGCPのサービスアカウント設定とセキュリティや機能面で重要な違いがあります。
Rupertはインテーク時にクラウドプロバイダー、CI/CDプラットフォーム、ランタイム、デプロイ先を尋ね、その組み合わせに特化した構成を生成します。出力は開発者が汎用テンプレートを環境に合わせて適応する必要がなく、そのまま環境で動作します。
DevOps経験のない開発者向け
Rupertは特に、よく構築はできるがインフラ経験が限られるフルスタック開発者に価値があります。専任のDevOpsエンジニアがいない企業の多くの開発者がこのカテゴリに該当します。エージェントは出力内で重要なアーキテクチャ上の決定をすべて説明します。なぜマルチステージDockerビルドがビルド依存関係をランタイムイメージから分離してイメージサイズを削減するのか、なぜ非rootユーザーでコンテナを動かすことがコンテナ脱出シナリオで重要なのか、なぜブルー/グリーンデプロイがダウンタイムをなくすのか、なぜリモートTerraformステートがチーム環境でのステートファイル競合を防ぐのかなど。
説明はコードやシステムの基本は理解しているがインフラ構成を学んでいる開発者向けに調整されています。出力は単に構成を提供するだけでなく、開発者のスキル向上を促し、Rupertに毎回頼らずにメンテナンスや拡張ができるようにします。
RupertとのDevOpsセッションの始め方
RupertのスキルファイルをClaude Projectsに読み込み、起動用のpromptを貼り付けます。Rupertはアプリケーションタイプ、言語とフレームワーク、クラウドプロバイダー、CI/CDプラットフォーム、デプロイ先、特定の要件や制約を一つずつ質問します。具体的に答えるほど、より正確な出力が得られます。実装手順付きの完全でコミット可能な設定ファイルを受け取れます。RupertはClaude、ChatGPT、またはシステムpromptを受け付ける任意のAIチャットで動作します。複雑なマルチ環境セットアップのチームは、環境ごとに別々のClaude Projectを用意することで設定を整理し、独立して更新可能にできます。
このガイドの背後にいるエージェント。スタックとクラウドプロバイダーを伝えるだけで、本番対応のDockerfile、CI/CDパイプライン、Terraformモジュールをセキュリティノート付きで受け取り、すぐにコミット可能です。