技術書典 19 において、所属している LayerX で LayerX Techbook 1 という書籍を有志で執筆し、その中で「人と SaaS と AI エージェントが協業する権限管理」というタイトルで寄稿しました。コーポレートエンジニアとして AI エージェントを活用してくためにどのようなことを考えて実践しているかについて書いています。

すでに技術書展のオンラインマーケットで購入可能なのと、明日 2025 年 11 月 16 日 (日) には物理本を売るのと僕も売り子として立ちます！来てくれ！！

この記事では僕が書いた章の中身を少しだけチラ見せします。コーポレートエンジニアリングと言いつつ Terraform、Kubernetes、React.js などの話をしています。

記事はこのような記事で構成されています:

  • AI エージェントと協働する未来
  • 決定的なシステムと非決定的なシステム、構造化データと非構造化データ
  • Infrastructure as Code による人とソフトウェアと AI エージェントの協業
  • AI エージェントのための安定的な基盤
  • LayerX における ID 基盤と人事基盤
  • ID 基盤と人事基盤を内製ソフトウェアで繋ぐ
  • 安定的な基盤の上で AI エージェントと協業する
  • Claude Agent SDK による AI エージェントの実装
  • 今後の展望とまとめ

以下は記事の中の「Infrastructure as Code による人とソフトウェアと AI エージェントの協業」という章をそのまま転載したものです。自分の Infrastructure as Code に関する考え方をまとめています。これが AI エージェントとどう繋がってくるのかはぜひ購入して読んでみてください！

Infrastructure as Code による人とソフトウェアと AI エージェントの協業

ところで、私は前職では SRE/Platform Engineer として働いていました。その時の経験も AI エージェントとの協業において重要な示唆を与えてくれています。

LayerX は複数の事業を展開していることもあり、AWS のようなクラウドサービスにおいては、個別の AWS アカウントは個別の事業部に管理を委譲しつつ、それを束ねる AWS Organizations はコーポレートエンジニアリング室で管理をしています。セキュリティ的なガードレールもそうですし、全社横断のドメインにおける DNS レコードの管理についてなどもコーポレートエンジニアリング室の管理の範疇です。これらの変更を行う際も、Claude Code のようなコーディングエージェントが活躍できる時代になってきました。例えば、AWS CLI がインストールされ、SSO で適切な権限を付与した状態であれば、Claude Code に指示を与えるだけでも AWS CLI を駆使して DNS レコードの変更ぐらいはできるでしょう。

ですが、Claude Code にインフラの、それも DNS のような重要なリソースを直接変更させることには大きなリスクが伴います。カレンダーへの個人的なランニングの予定の登録が 19:00 になるか 20:00 になるかは大した問題にならないと思いますが、間違ったレコードを更新したり、レコードに対して間違った値を登録してしまうことは、システムへの重大な障害を引き起こすことにもつながりかねません。このようなやり方は、例えモデルが進化したとしても適切とは言えないでしょう。

LayerX においては、クラウドリソースの管理には複数の事業部・部署で Terraform が利用されており、コーポレートエンジニアリング室でもそのための CI/CD 基盤を構築・運用し、全社に向けて提供しています。 (さらに、各事業部固有のアプリケーション等は各事業部で持つ別の CI/CD 基盤上で管理されています) これらの CI/CD 基盤では、Pull Request を作成すると terraform plan によるインフラへの変更内容がコメントとして投稿され、レビュアーの承認後にマージすることで terraform apply コマンドによって実際に変更が適用されます。また、CI/CD パイプラインには Trivyhttps://trivy.dev というセキュリティスキャンを行うソフトウェアも組み込まれているため、問題を検知したらそれも Pull Request 内で通知され、問題を解消するまではマージすることができないようになっています。

また、Terraform が持つ大きな特徴として、 「宣言的なリソース管理」 というものが挙げられます。例えば EC2 にインスタンスを作る場合、シェルスクリプトによる自動化であれば aws ec2 run-instances というコマンドに適切なパラメータを与えることで実現できます。これは「命令的」と呼ばれる自動化の手法です。これはこれで素朴でわかりやすくて良いのですが、そのスクリプトを複数回実行すると不要なインスタンスが増えていくかもしれません。Terraform であれば「このインスタンスはこのように作るべき」というあるべき状態を記述して実行すると、その状態に収束するような変更が行われます。インスタンスが起動していなければ新たに起動しますが、すでに適切な状態で起動済みであれば何もしません。これは「宣言的」と呼ばれる自動化の手法です。

少し飛躍しているように感じる方もおられるかもしれませんが、これはここ 10 年におけるソフトウェアの大きな潮流だと考えています。それまでの命令的なやり方を宣言的なやり方に変えたソフトウェアとして、インフラの領域においては Terraform と Kubernetes がそうでしたが、フロントエンド開発の領域においても React.js は宣言的な DOM 管理を採用しています。いずれも今から 10 年ほど前の 2014 年前後に登場しているという点も興味深いです。これらはリソースを 「あるべき状態」 と 「実際の状態」 を比較した上で 「あるべき状態に収束させる」 ことをベースとしたアーキテクチャとなっており、安定的なソフトウェアを構築する上で避けることのできない考え方だと考えます。

このように、Terraform によってインフラをコード化することは、人間がコードレビューという形で介入する余地を与えるだけでなく、ここでも Trivy のような決定的なソフトウェアによって支援を受けることができますし、宣言的なリソース管理によって安定して運用することが可能になります。これら自体は以前から良いとされていたプラクティスでしたが、人間やソフトウェアがガードレールとして機能している中でコーディングエージェントと協業することにより、これまで以上の効率で構成変更を行うことができるようになりました。