はじめに
「AIはボトルネックを解消するものではなく、ボトルネックを他の工程に移しているだけ」という話を聞きました。私はシステム導入の中でAIを使いこなせているわけではないのですが、当然一部にはAIを活用しているため、改めてどのようにシステム導入の工程を実施していて、どこにボトルネックがあるのかを振り返ってみました。
前提
ざっくりと導入工程を書いてみます。工程は下記のように、要件定義・検証・設計・構築・試験・運用の6つとします。検証をいつ実施するかはプロジェクトによっても異なります。要件定義後に実施する場合もあれば、PoCや検証事業として別に実施する場合もあります。各工程で何をインプットにして何をアウトプットしているか、そして自分がどこに時間をかけているかを図にすると、下記のような形になります。
要件定義はおいておいて、オレンジ色の検証と緑色の設計が手動作業の多い箇所です。
今回の記事の導入システム例はシンプルに下記とします。AWS上にEC2サーバを構築して、パッチ適用・バックアップ取得・システム監視を行います。
検証
一番時間をかけているのは検証の時間です。ここでマネジメントコンソールから細かい動きまで見ていきます。例えばPatch Managerはどういう動きをするのか。
ただ単にパッチが当たるだけでなく、例として下記のような項目をマネジメントコンソールでポチポチやりながら見ていきます。
- 適用するパッチがあるときはどうなるか、ない場合はどうなるか
- サーバが停止していた場合はどうなるか
- 適用後に勝手に再起動されないか
- 何か発生した際に問題解決できるようなログは出力されているか
- Patch Managerでの適用と同時に手動で適用をしてみたらどうなるか
動きと一緒に、どういったパラメータを設定するとどういった動きになるかも、ここで見ていきます。例えば、詳細設計以降のフェーズでパラメータシートを作成しますが（下記はClaude Codeで作成したサンプル）、このパラメータはどういった意味か、設計根拠は何かを考えていきます。
AIを使用して行っていくので、検証した情報は実際に行った結果や設計根拠の情報として蓄積されていきます。
設計
要件や検証した情報から設計書・パラメータシートを作成します。ここは要件や検証情報をインプットとして使用して自動化できている箇所もありますが、フォーマットや構成図作成、図の差し込みなど、まだ手動でやっている箇所が多いので、もう少し自動化を行いたいと思います。
構築、試験
構築・試験のフェーズは多くの箇所で自動化ができています。
- パラメータシートからIaCのコードを作成する
- 検証情報・設計情報から、マークダウンの構築手順書と試験仕様表を作成する
実際の構築は、構築手順書をAIに読ませながらIaCのコードを使用して構築します。試験も試験仕様書をAIに読ませながら実施して、試験成績書と試験エビデンスを作成します。
運用
検証時の情報や構築時・試験時の情報も、AIと実施したためMDファイルにノウハウがたまっています。なぜこういった設定にしたのかとか、ここでうまくいかなかったとか、いわゆる今までは暗黙知だった情報が形式知化しています。そのため、これらの情報を使用すれば運用フェーズでの再現性の向上につながります。
ボトルネックになっている項目
冒頭の図を再掲します。
ボトルネックとなっている個所は、オレンジの「検証」の項目と、緑の「設計書・パラメータシート」の項目です。構築より先のフェーズは多くの箇所で自動化ができています。前述のとおり、設計書・パラメータシートの項目はもう少し自動化したいと思います。
ただ、検証の箇所は今まで通り時間をかけてよいと思っています。逆に、ここで多くの時間をかけてシステムの動きを理解できるからこそ、後続の工程が自動化できていると思っています。
例えば、パッチを適用するテストを考えます。試験仕様書では、可能な箇所はコマンドで実行します。パッチの適用や確認もAWS CLIやPowerShellを使用して適用して、結果が返ってきます。システムの動きを理解しているため、コマンドや実行結果に関しても理解ができ、OK・NGの判断ができます。しかし、あまり理解していない状態で、なおかつCLI実行だと、AIが出してくる回答になかなか判断がつきづらくなってしまいます。あとは、この検証の箇所が一番面白いです。また、AIの活用によって基礎的なインフラ知識を身に付ける機会が少なくなってきているという話もありますが、こういった検証の箇所を実際に手を動かしながらやっていくと、まだまだインフラの基礎知識は身に付きますね。
まとめ
基礎知識習得のためにも、後工程の自動化のためにも、検証を含めたシステム理解の箇所に関しては手動で多くの時間を使っているという話でした。