インフラチームでAIの利用推進活動をした話とその成果

記事タイトルとURLをコピーする

はじめに

私が所属するプロジェクトで、約半年間にわたりAIの利用推進活動を行いました。その進め方やプロセスの詳細について解説します。

対象

  • これから業務でAIを活用したいが、進め方がわからない方
  • 個人でAIを利用しているが、チームとしての成果につなげたい方

前提

本記事の内容は、私が特定のプロジェクトで推進した活動記録です。具体的には、業務プロセスの一部としてAIを利用するための活動であり、システムにAIを組み込むような技術的な内容ではありません。また、具体的なAIツールの選定やチューニングについても触れていません。

プロジェクトの基本業務概要

  • AWS基盤のインフラ改善・最適化
  • インフラ監視の最適化、セキュリティサービスの棚卸しと是正
  • 一部AWS以外のSaaSの導入、最適化
  • インフラエンジニア:4名

半年間の活動で得られた成果(サマリー)

本格的なプロセスの解説に入る前に、約2ヶ月間の集中測定期間で得られた数値と成果を共有します。

導入効果

4名のエンジニアによる計9つの実務タスクの分析結果

評価項目 結果(サマリー)
効率性 66% のタスクで速度向上
品質 77% が手動と同等以上の品質
満足度 平均 3.9点 / 5.0点

数値化できない気づき

  • AIの得意/不得意
    大量のドキュメントからのキャッチアップや、AWS CLIを自然言語で操る作業では圧倒的な速度(3倍以上)を記録しました。一方で、緻密な計算が必要なコスト集計などではハルシネーションが発生し、かえって修正に時間がかかることも確認されました。
  • タスクの解像度
    何を作るかが曖昧なままAIに投げてしまい、品質が下がることが確認できました。作業者自身が成果物のイメージを固め、適切なコンテキストをエージェントに与えられるかどうかが、品質を左右することがわかりました。
  • 個人の能力による差
    AIを使いこなすほど、指示を出す作業者側の「設計力」や「意思決定力」の重要性が浮き彫りになりました。ツールを標準化するだけでなく、個人の技術力もAIを使いこなせるかどうかを左右することがわかりました。

このように、AIは万能ではないということを改めて実感し、使うタスクの見極めと適切な使い方が効率的なAI利用においては重要であることが浮き彫りになりました。 では、具体的にどのようなステップでこの活動を進めたのか、順を追って解説します。

やったこと

  • ヒアリング
  • ディスカッション
  • 効果が出そうなポイントの見極め
  • 実施
  • 効果測定
  • 指針の策定
  • 改善フィードバックループ

ヒアリング

まずは、プロジェクトメンバーや組織に対して、AI利用の必要性と利用状況をヒアリングしました。これは、プロジェクトの活動として本格的に進めても問題ないかを見極める作業です。

対象は、実務を担うエンジニアだけでなく、成果物のレビューや受け入れを行うステークホルダーも含めました。ただし、対象を広げすぎるとアクションが遅れる可能性があるため、後続のディスカッションに向けた軽い相談を心がけました。

当時、AIエージェントへの注目が高まっており、自社でAmazon Q Developerの利用が推進されたことを機に、チームでより活用したいという機運がありました。これが、プロジェクトの活動として推進しようと考えたきっかけです。

ヒアリングのポイント

  • 普段の業務で効率の悪い作業はないか
  • その中で、AIを使って効率化できそうなタスクはあるか
  • すでにAIを利用している場合、より効率的に使いたいチームで標準化したいといったニーズがあるか

ディスカッション

ヒアリング情報が揃ったところで、チーム内でディスカッションを行いました。ここではヒアリング内容をベースに、AI利用のアイデアを広く募ります。

メンバーがすでに他プロジェクトや個人で利用している可能性もあるため、トレンド共有を含めたオープンな場にすることを意識しました。 サービスへの機能組み込みだけでなく、日々の運用オペレーション業務プロセスの一部に取り入れるなど、システムを作り込まなくても活用できるポイントも含めて発散させることが重要です。

効果が出そうなポイントの見極め

アイデアを出し切った後、最も効果が出そうなポイントを絞り込みます。

チームとして何を価値とし、何を達成したいのかを再確認し、それを前提に最も成果が出る方法を定義します。活動にはコストが伴うため、実施する価値と見込みを言語化し、きちんと精査しました。これにより実りあるAIの利用推進活動になることを目指しました。

私の場合、まずは日々の業務のタスクをできる限り洗い出して可視化し、効率の悪そうなタスクや質に影響を与えやすいタスクを改めて確認して絞り込みました。

可視化した図の一部

より価値が出やすいタスクとして、AIの相性が良さそうな再現性の高い作業にスコープを絞りました。

具体的には、手順書作成月次/週次レポートの作成などです。 これらはあらかじめフォーマットが決まっており、必要な情報も出揃っている一方で、作業時間が長く負荷が高いという課題がありました。

これらを対象スコープとし、チームで標準化したルールのもとでAIを利用することを決定しました。

AI利用におけるポリシーを確認する

組織によっては、AIの利用自体が禁止されていたり、詳細なルールが策定されていたりする場合があります。

無意識に利用した結果、後から問題に発展することがないよう、事前にステークホルダーへの確認やプロジェクトの制約を確認しておきましょう。もし障壁となるルールがあれば、この段階で調整が必要です。

AI利用の準備

チームで利用するにあたっては、以下の準備を行いました。 具体的にはKiro CLIで業務タスクを実行できるように基盤を整備しました。

利用するツールの利用申請

先述の通り、自社ではAmazon Q Developerが推進されていたため、 Kiro CLIを使用できるように社内で利用申請しました。

簡易的な操作ドキュメントの作成

GitHubリポジトリを作成してREADME.mdなどのドキュメントに基本操作を記載してチームメンバーへ共有しました。

レクチャー(使い方の周知)

私の場合は個人プロジェクトなどですでにツールの使い方はキャッチアップできていたため、 ツールの経験がないメンバー向けに実務でのAI利用方法をレクチャーしました。

プロンプトへの具体的な指示の入力の仕方や考慮すべきポイントについて詳しく解説しました。

必要最低限のルールとカスタムエージェントの整備

手順書作成のタスクは、手順書テンプレートを作成して実現したいタスクを指示すればテンプレートに沿った手順書を作成してくれるKiro CLIのカスタムエージェントを作成しました。 作成したエージェントはGitHubのリポジトリへpushし、チーム共通で同じエージェントを利用できるように必要最低限の基盤を整備しました。

また、基本的なプロジェクトのルールもKiro CLIの設定へ反映させました。

Kiro CLI専用のリポジトリディレクトリ構成

※添付の画像はAmazon Q Developer CLIを利用していた頃に作成した構成です。現在はKiro CLIにアップデートされておりディレクトリ構造は変更されています。

実施

準備が終わって実施フェーズで実際に業務タスクでAIを利用して運用していきます。

対象スコープは絞りつつも、最低限のルールを遵守した上で利用するタスクはチームメンバーに委ねました。

また、試してもらったら可能な限り短期間でフィードバックを得ることを重視しました。 ルールの微調整やうまくいかなかった挙動があれば共有してもらってすぐに是正するように心がけました。

AI領域は進化が激しく、期待していた効果が出ないことや、別の活用ポイントが見つかることも多々あります。すぐに試して評価することで、無駄な時間をかけずに軌道修正が可能になります。

効果測定

ある程度の手応えが得られた段階で、具体的な数値を元に成果を可視化します。

AIの評価に唯一の正解はありませんが、今回は先述の通り、以下の3軸で評価しました。

  • 効率性(作業時間の短縮)
  • 品質(成果物の精度)
  • 満足度(使い心地やストレスの変化)

実際にはもっと緻密に削減時間などを計測することも不可能ではないと思いますが、今回はより早く成果を出すことにこだわったため、 あくまで体感ベースで結果を募ることにしました。

集計方法については、フィードバック形式で上記の評価を募るフォームを作り、 Kiro CLIのカスタムエージェントを利用してフィードバック収集専用エージェントを作成しました。

メンバーはそれぞれKiro CLIを使って利用したタスクが終わった時点で、エージェントを起動し、プロンプトで表示されるアンケートに回答することで 生成された測定結果ファイルをリポジトリへpushしてもらい、後日それらを一括して集計しました。

フィードバック収集専用エージェント

$ kiro-cli chat --agent feedback-collector
...

[feedback-collector] 25% > フィードバックアンケートに回答します。

> フィードバック収集を開始します。

まず、最近の作業コンテキストから以下の情報を認識しました:

推測される作業内容:
- **チケット番号**: XXXXXX(hogehoge設定最適化_作業実施)
- **作業概要**: PRレビュー対応完了、本番環境へのhogehoge適用準備
- **所要時間**: 約1-2時間程度(2026-01-16の作業)

この内容で正しいですか? (Y/修正内容を入力)

 ▸ Time: 7s

[feedback-collector] 38% > Y

> ありがとうございます。それでは、フィードバックアンケートを開始します。

### 基本情報の確認

### 1. 実際の所要時間
XXXXXXのPRレビュー対応作業に、実際にどれくらいの時間がかかりましたか?
(例: 2時間、30分、1時間30分)

 ▸ Time: 23s

[feedback-collector] 38% > 1時間30> ### 2. 利用エージェント
この作業で主に利用したエージェントを教えてください:

- デフォルトエージェント
- ticket-startup
- manual-writer
- report-writer
- cost-analyzer
- その他(自由入力)

どのエージェントを使用しましたか?
...

指針の策定

効果測定の結果を元に、チーム内でのAI利用における指針を策定することにしました。 これによって実態に伴ったルールを整備し、よりAIの利用が活性化されて成果を持続することができます。

策定した指針は機会があれば別の記事でご紹介します。

改善フィードバックループ

先述の通り、AIは常に進化し続けています。それに伴い、新たな課題やより良い手法が日々生まれています。 策定した指針やプロセスを固定化せず、常に最新の情報に基づいてブラッシュアップし、実情に即した運用を続けることが重要です。

やってみた感想

活動を通じた見極めの段階で、日々の業務を分解・可視化したことにより、業務プロセス全体を俯瞰して再認識することができました。このタスクは何のためにあるのか前工程で何を終わらせておくべきかといった本質的な振り返りにつながりました。

効果測定では、期待通りに成果が出たものと、そうでないものが明確に分かれました。 これは失敗ではなく、気づきを得て次のアクションを取れるようになったことが大きな収穫です。AIを使わなければ、この良し悪しの判断すらできませんでした。

また、AI利用は認知負荷の増大個人の成長への影響といった側面もあります。無意識に使っていると気づきにくい点ですが、チームでフィードバックを出し合うことで、AIを客観的・懐疑的な視点でも評価することができました。

どなたかの参考になれば幸いです。

折戸 亮太(執筆記事の一覧)

2021年10月1日入社
アプリケーションサービス本部ディベロップメントサービス3課

屋根裏エンジニア