AIペアプロで設計判断が速くなった話
設計判断に時間がかかるタイプだった。「この構成でいいのか」「もっといい方法があるんじゃないか」と考え続けて、手が止まる。AIに壁打ち相手になってもらったら、判断のスピードが上がった。
一人設計の限界
インフラエンジニアの仕事は、設計判断の連続。ネットワーク構成、リソース配置、認証方式、モニタリング設計。正解が一つではない問題を、一人で考えて決める場面が多い。
チームメンバーに相談できればいいけど、全員が忙しい。レビュー会を設定するほどでもない小さな判断が積み重なって、進捗が遅くなる。
ドキュメントを読んで、ブログ記事を検索して、過去のPRを漁って。情報を集める時間だけで30分、1時間と過ぎていく。集めた情報を整理して比較検討する時間も含めると、小さな設計判断一つに半日かかることもあった。
AIを壁打ち相手にする
Claude Codeに設計案をぶつけてみた。「このKubernetes構成でスケーラビリティは問題ないか」「この認証フローに穴はないか」。
AIは即座に回答してくれる。待ち時間ゼロ。しかもメリット・デメリットを構造的に整理してくれるから、判断材料が揃う。
実際のワークフロー
自分がやっているAIペアプロの流れは、だいたいこうなる。
まず、課題と制約条件をClaude Codeに伝える。「GKEクラスタ間のサービス通信を設計したい。レイテンシは50ms以下、既存のIstioメッシュと共存させたい」のように、背景と要件をセットで渡す。ここが雑だと回答も雑になるので、前提条件の言語化は丁寧にやる。
次に、AIが出してきた設計案を読んで、自分の環境に当てはまるかを判断する。「この案はうちのネットワーク構成だと無理だな」「これは運用コストが高すぎる」と、環境固有の制約でふるいにかける。
残った候補について「方式Aと方式Bの運用負荷を比較して」と深掘りする。ここでAIが整理してくれた比較表をベースに、最終判断を下す。
このサイクルが1回10〜15分。以前は同じ結論に至るまで2〜3時間かかっていた判断が、大幅に短縮された。
効果があった場面
代替案の洗い出し。自分が思いついた設計案が1つだけの時、AIに「他のアプローチは？」と聞く。3〜4つの代替案が出てくる。全部が使えるわけじゃないけど、視野が広がる。
トレードオフの整理。「方式Aと方式B、どっちがいい？」と聞くと、パフォーマンス、コスト、運用負荷、複雑さの観点で比較表を作ってくれる。自分の頭だけだと、偏った観点で判断しがち。
エッジケースの発見。「この設計で問題が起きるケースは？」と聞くと、自分が見落としていたエッジケースを指摘してくれることがある。障害パターン、同時実行、リソース枯渇。
既存設定のレビュー。Terraformのコードやマニフェストを渡して「この設定で見落としている項目はあるか」と聞く。セキュリティグループの設定漏れやリソースリミットの未設定など、チェックリスト的な確認をAIに任せると楽になる。
人間とAIの役割分担
AIペアプロを続けてわかったのは、人間とAIで得意な領域がはっきり分かれること。
AIが得意なのは、選択肢の網羅的な列挙、一般的なベストプラクティスの提示、構造的な比較整理。要するに「広く浅く、速く」の仕事。
人間が担うべきなのは、チーム固有の文脈を踏まえた最終判断、ビジネス要件との優先度調整、過去の障害経験に基づくリスク評価。こっちは「狭く深く、正確に」の仕事。
この切り分けを意識してから、AIとのやり取りが格段にスムーズになった。AIに「決めてくれ」と期待するのではなく、「材料を揃えてくれ」と依頼する感覚。
AIの判断を鵜呑みにしない
重要なのは、AIの回答を「参考意見」として聞くこと。最終判断は人間がする。
AIは一般的なベストプラクティスを回答するけど、自分たちのチームの文脈を知らない。既存システムとの互換性、チームのスキルセット、運用体制。これらを考慮した判断は人間にしかできない。
AIの回答で「なるほど」と思うことと、「うちの環境では違うな」と思うことが半々くらい。この取捨選択をするのが人間の仕事。
一度、AIが提案したネットワーク構成をそのまま採用したら、既存のファイアウォールルールと競合して障害になりかけたことがある。AIは既存環境の全体像を知らないから、こういうことが起きる。それ以来、AIの提案は必ず既存構成と突き合わせてから採用するようにしている。
設計レビューの質も上がった
AIとの壁打ちを経てから設計レビューに出すと、レビューの質が上がった。
事前にAIと議論しているから、想定される質問への回答が準備できている。代替案を検討した上で「この方式を選んだ理由」を説明できる。
レビューが「これで大丈夫？」から「ここまで検討した上でこれにした」に変わった。
レビュアー側の負担も減る。検討過程が整理された状態で出てくるから、「そもそも他の方法は考えた？」という手戻りが少ない。
導入時に気をつけること
AIペアプロを始めるなら、いくつか注意点がある。
機密情報の取り扱い。社内のコードやインフラ構成をAIに渡す場合、機密情報が含まれていないか確認する必要がある。認証情報やAPIキーをうっかり貼り付けないよう、習慣的にチェックする。
AIの回答を検証する手段を持つ。AIが「この設定で問題ない」と言っても、実環境でdry-runやplanを実行して確認する。AIの自信満々な回答が間違っていることは珍しくない。
チーム内でのAI利用の共通認識。「AIが提案したからこの設計にしました」では、レビューで説得力がない。AIは判断材料を集めるツールであって、判断の根拠にはならない。この認識をチームで揃えておくと、変な依存が生まれにくい。
判断の速度と質は両立する
以前は「速く決める」と「正しく決める」がトレードオフだと思っていた。急いで決めると見落としが出る。慎重に考えると時間がかかる。
AIとの壁打ちを挟むと、短時間で多角的に検討できる。判断の速度と質が両立するようになった。
ただし、AIに頼りすぎると自分の設計力が伸びなくなるリスクはある。AIの回答を読んで「なぜそう判断するのか」を理解する姿勢は大事。AIが出した結論だけを使うのではなく、そこに至る思考過程を追いかけることで、自分の引き出しも増えていく。
関連記事
他の記事
ブラウザ横スクロールアクションゲーム開発記｜TypeScript×Canvasで作るネオンランナー
HTML5 CanvasとTypeScriptで横スクロールアクションゲーム「ネオンランナー」を自作した。物理エンジン、衝突判定、操作性の工夫を解説する。
ブラウザで遊べるテトリス風パズルをTypeScriptで作った話
HTML5 CanvasとTypeScriptでテトリス風ブロックパズルを実装した。エンジンとUIを分離するSnapshotパターンや、ネオン演出のこだわりを解説する。
ゲーム実況のサムネイル作りで学んだデザインの基本
非デザイナーがゲーム配信のサムネイルを自作し続けて気づいた、視認性・配色・構図の基本ルール。試行錯誤の記録。
配信のコメント欄が動いた瞬間の話。ゼロからイチの体験
ゲーム配信でコメントがゼロの日々を超えて、初めてリアルタイムでコメントが来た瞬間の話。ゼロからイチの体験がモチベーションを変えた。