見出し画像

【Fable 5】AIにインフラ作業を任せられるようになってきた

インフラ作業をAIエージェントに任せる——少し前まで、これはかなり勇気のいる選択だった。だがClaude Fable 5を使い始めて、その感覚が確実に変わってきている。

前提となる作業環境

まず、どういう環境で何をやっているかを整理しておく。

インフラはクラウド環境で、基本的にTerraformで管理している。細かい操作の一部はCLIで補う、というスタイルだ。この構成自体は以前から変わっていない。

厄介なのは、デプロイの経路だ。ローカルから直接クラウドへデプロイすることはできない構成になっている。そのため、GitHub ActionsのWorkflow dispatchを叩いてデプロイを起動し、CIの実行状況を監視しながら結果を待つ——という手順を踏む必要がある。

つまり、ここでAIに任せたいのは「ローカルで開発したアプリケーションをクラウドにデプロイする」という一連のタスクだ。単にコードを書けばいいのではなく、デプロイの起動、CIの監視、結果の確認まで含めた、それなりに手数の多い工程になっている。

Opus時代の「任せられなさ」

これまでもAIにこの手の作業を振ろうと試みてはいた。だが、Opusには安心して任せられなかった。開発環境を何度も壊された。一度や二度ではない。

結局、任せたはずの作業を自分で巻き戻し、修正し、やり直す羽目になる。それなら最初から自分でやったほうが早い、という状態が続いていた。

Fable 5で変わったこと

Fable 5に切り替えてから、この構図が明確に変わった。

一番大きいのは、一連の流れを一気通貫で任せられるようになったことだ。設計レビューを経て実装に入り、開発環境へデプロイし、動作確認を行い、最終的にPR作成まで。この一連のプロセスを、途中で手を入れることなく走らせられるようになった。

先述の通り、デプロイはWorkflow dispatch経由でCIを監視する必要があるが、その手順も含めて任せられる。Opusでは、どこかで必ず引っかかって手動介入が必要になっていた工程だ。

動作確認の「賢さ」

特に印象的だったのが、動作確認の場面だ。

対象となるアプリケーションは、認証やIP制限を備えた、そこそこセキュアな構成になっている。この手のアプリは、単純に叩けば動作確認が完了するわけではない。認証を通す必要があるし、アクセス制限も考慮しなければならない。

Fable 5は、こうした制約を踏まえた上で、適切な動作確認の方法を自分で選んで実行できていた。「とりあえずリクエストを投げて失敗する」のではなく、環境の前提条件を理解した上で正しい検証手段を選択する——この判断ができるかどうかが、インフラ作業を任せられるかどうかの分かれ目だと感じている。

まだ任せていないところ

正直に言うと、タスクレベルまで粒度を落とし込めば、「これはできない」という場面は今のところほとんどない。ここまで来たか、というのが率直な感想だ。

一方で、あえて任せていない領域はある。ブラウザ経由での認証だ。

技術的には、Playwrightを使えばブラウザ操作も自動化できるので、やろうと思えば任せることはできる。ただ、ここはセキュリティ上の最後の砦という感覚がある。認証情報を扱うブラウザ操作までエージェントに握らせるのは、今の自分の中ではまだ一線を越える。だから、ここは意図的に手元に残している。

「できない」から任せないのではなく、「できるけれど任せない」という判断——この線引きを自分の中で持てるかどうかも、AIエージェントと付き合っていく上では大事なポイントだと思っている。

まとめ

まだ「完全に目を離せる」段階とは言わない。だが、Opus時代の「結局自分でやり直す」前提から、「レビューして走らせれば形になる」前提へと、確実にステージが上がってきている。

インフラ作業は失敗のコストが高い領域だ。だからこそ、ここを安心して任せられるようになってきたインパクトは大きい。Fable 5は、AIエージェントに任せられる作業範囲を一段階押し広げてくれたと感じている。

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