見出し画像

進化と制約──エンジニアマネジメント×AI

もうこれ、手作業じゃ間に合わないぞ

OCR関連のタスクを進めていたとき、私たちは壁にぶつかっていました。納期が迫る中、従来の手法ではどう計算しても終わらない。そこで半ば強制的に、クラウドベースのAIコード生成ツールに頼らざるを得なくなりました。 それが、チームでAI活用が一気に加速した瞬間でした。今となっては、AIは手放せない存在です。

今回は、iCAREのDevelopment部でSREチームに所属し、インフラ構築や運用基盤を担う羽生さんに、特にIaCや運用保守の領域でAIを実業務に導入したことで見えてきた変化と、それに伴って浮き彫りになった組織の課題について聞きました。

インフラ基盤の構築や運用保守において、AIはどう機能しているのか。現場の声をお届けします。

※本インタビューは2026年5月に実施したものです。掲載内容は当時の情報に基づいているため、現在の取り組みとは一部異なる場合があります。あらかじめご了承ください。

【プロフィール】
株式会社iCARE Development部 SREチームマネージャー。ソーシャルアプリ、Webサービス、MSP領域でインフラ設計・構築・運用、運用設計、チームマネジメントを経験。現在はCarely健康管理クラウドの信頼性とパフォーマンス向上を目的に、AWS/GCPインフラ、CI/CD、監視基盤、運用改善を担当。IaCや運用保守におけるAI活用にも取り組み、開発と運用をつなぐSRE組織のマネジメントを担っている。

インフラ構築の0→1をAIが変えた

── 現在のプロジェクトでのAI活用状況について教えてください。

羽生: チームとしても個人としても、インフラの構築やIaCの領域で全面的にAIを活用しています。主に使っているのはClaude CodeやDevinですね。先ほどお話ししたように、IaCの記述量が圧倒的に多い構築案件をきっかけにAIを本格的に使い始め、今では完全に手放せない状態になっています。

── 実際に使ってみて、どのあたりで最も効果を感じていますか。

羽生: 0から1を作る構築フェーズでは、スピードが格段に上がります。「何を作るか」という要件さえ明確に決まっていれば、数千行のコードでもAIが一気に書き上げてくれます。インフラ構築は、実装そのものよりも、要件整理や既存構成の調査、設計・検証に多くの時間がかかります。AIの導入によって、特にIaCのコードを書く部分の負荷は大きく下がりました。

── 逆に、AIが苦手としている部分はありますか。

羽生: 運用保守のフェーズですね。既存のシステムに対して「現状どうなっているか」を正確に把握し、変更を加えたときに他へ影響が出ないようリスクヘッジする。一方で、運用保守のフェーズでは注意が必要です。コード管理やドキュメントが整っている環境であれば、AIが既存構成をかなり正確に把握してくれる場面もあります。ただし、過去にその設計を選んだ理由や、他チームとの合意、運用上の制約といった背景までは、明示的に残しておかないと読み取れません。そこはまだ人間の判断が必要です。

コンテキストを渡すためにドキュメントを書く

── AIに「なぜ」を理解させるのは難しいと。そこは人間がカバーするしかないのでしょうか。

羽生: 適切なコンテキストを与えないと、AIは的外れなものを出力してしまいます。インフラは単体で完結するものではなく、プロダクトの法的要件、社内のセキュリティ基準、監査・認証上の要件、他チームとの役割分担といった制約条件の上に成り立っています。

── そうした前提条件を、どうやってAIにインプットしているんですか。

羽生: それが大きな課題でした。実はこれまで、細かい仕様やルールをドキュメントとして残す文化があまり根付いていなかったんです。開発を優先して、ドキュメント化は後回しになりがちでした。 ですがAIを使うようになると、AIにコンテキストを渡すために、人間がドキュメントを書かなければならない状態になったんです。

── AIに仕事をしてもらうために、人間の仕事が変わったんですね。

羽生: はい。今は社内規定や要件をまとめたドキュメントをGitHubで管理し、それをAIに読み込ませて「マストで実装すべき要件」を抽出させてからコードを書かせています。 ただ、そのドキュメントを書く作業自体もClaude Codeなどを使うことでかなり楽になりました。ゼロから書き始めるのではなく、AIにたたき台を作らせ、人間が前提条件や制約、判断理由を補正していく進め方に変わっています。

新人育成とマネジメントの新たな壁

── AIの導入によって効率化が進む一方で、新しく見えてきた組織的な課題はありますか。

羽生: 懸念としてあるのは、新人エンジニアの育成です。これまではエラーが出たら自分で調べて、ドキュメントを漁って、先輩に聞いてというプロセスを経てアーキテクチャの理解を深めていました。 でも今は、エラーをAIに投げれば数秒でもっともらしい答えが返ってきます。

── 答えにすぐ辿り着けるのは良いことのように思えます。

羽生: 平常時は良いんです。ただ、AIが間違った回答を出したときに「これはおかしい」と疑うリテラシーや、根本的なアーキテクチャの理解がないと、致命的な障害時に対応できなくなります。「AIに言われた通りにやりました」では済まされない領域がインフラにはあります。 AIを使って正解体験を積み重ねるだけでは、いざというときのサバイバル能力が育ちにくい。これは組織として向き合わないといけない問題です。

── マネージャー層にとっても、新たなマネジメントスキルが求められそうですね。

羽生: その通りです。AIが生成したコードの品質をどう担保するのか、入力してはいけない情報をどう制限するのか。そして、ツールの費用対効果をどう評価するのか。 単に「AIで便利になりました」ではなく、AIを組み込んだ新しい開発プロセスをどう統制していくかが、今後のマネジメントの大きなテーマになっていくと感じています。

現場の試行錯誤は続く

AIはコードを高速で生成してくれます。しかし、そのコードが「なぜ」必要なのかというコンテキストを整理するのは、依然として人間の役割です。以前は実装後に整理されがちだった要件や制約を、AIに正しく伝えるために先に書くようになる。この逆転現象は、現場で起きているリアルな変化でした。

iCAREの開発組織は、AIの恩恵を享受しつつも、新人育成や品質担保といった新たな壁に直面し、日々試行錯誤を続けています。


読んでくださってありがとうございました。
この記事が「なるほど」と思えたら、「スキ」や「フォロー」もらえるとうれしいです。チームにもシェアしてもらえると、次の記事のモチベーションになります。


iCAREではエンジニアを募集しています

iCAREでは、「Carely健康管理クラウド」を共に開発していくエンジニアを募集しています。 これまでの経験を活かし、複雑な社会課題の解決に技術で挑戦したい方、ぜひ下記より詳細をご覧ください。


いいなと思ったら応援しよう!