--- 
はじめに
株式会社QualiArtsでバックエンドエンジニアをしている岸端です。 普段はチームのマネジメントをしながら、基盤開発やセキュリティ推進に取り組んでいます。
近年はAIへの投資が加速し、AIツールの性能も向上しています。 ワークフローにAIを取り入れることで、作業効率や品質の向上が期待できる場面も増えてきました。 一方で、AIをワークフローにどの程度取り入れているかは、プロジェクトや職種によって差があります。 とくにエンジニアはAIツールを使った効率化が進みやすい一方で、他の職種では活用状況にばらつきがありました。
もちろん、あえてAIを使わない選択をすることもあります。 一方で、定常的に発生する一次調査や一次レビュー、決定論的な処理にはしにくいものの言語化しやすいタスクでは、AIによって作業効率や品質を高められる可能性があります。 本記事では、こうした観点からQualiArtsの運用プロジェクトでAI効率化を進めるために取り組んでいることを紹介します。
職種ごとの業務を知る
ゲーム開発では、大きく分けてエンジニア、プランナー、クリエイターの3つの職種が関わっています。 AIを取り入れることで、定常的なタスクの効率化、職種を越えたタスク支援、成果物の品質向上が期待されています。 AI活用は職種ごとに進めることもできますが、AIツールの扱いに慣れている職種がサポートすることで、より効率的に広げられると考えています。 そのためには、各職種が担当するタスクの特徴を理解し、どの領域でサポートできるかを見極めることが重要です。
大別すると3つの職種ですが、同じ職種内でもより細かく分けることができ、タスクは多岐にわたります。 一方で、職種が異なっても「進捗管理」や「レビュー」といったタスクは発生します。 具体的な内容は異なりますが、タスクの流れには共通点も多くあります。 このように性質が近いタスクでは、自分たちの職種で得たAI活用の知見をもとに、他職種での活用方法も検討できます。
AI活用を広げるうえでは、日々のコミュニケーションが重要です。 また、AIを使ってコミュニケーションの質を高めることもできます。 AIチャットボットを使って対話の内容を整理することで、相手への理解を深めたり、相手が理解しやすい形で説明したりしやすくなります。 プロジェクト全体でAI活用を広げるには、互いのタスクの特徴を理解し、職種を越えてサポートし合うことが重要です。
3つの基本方針
新規開発プロジェクトであれば、最初からAIを活用した効率的なワークフローを模索できます。 一方、運用プロジェクトでは既存のワークフローを維持しながら、段階的にAIを活用した効率的な形へ近づける必要があります。 そのためには、プロジェクト内にAIを活用できるメンバーを増やし、AIによる効率化を徐々に広げていくことが重要です。 私たちのチームでは、以下の3つを基本方針にしています。
- エンジニアから他の職種へ広げていく
- AIの恩恵を実感できる機会を増やし、AIに前向きな価値観を広げる
- 同一職種の中でサポートし合えるように、環境の差異を最小化または隠蔽する
コーディングエージェントの進化や、AIへの理解のベースラインの高さを考えると、エンジニアはAI活用の恩恵を得やすい職種です。 また、エンジニアは、権限管理や環境分離などのセキュリティ上の考慮事項をAI登場以前から普段の業務で扱ってきています。 そのため、他の職種と比べてもAI活用を負担を抑えながら安全に進めるための知識や経験を持っている場合が多いです。 だからこそ、まずエンジニア自身がAIを活用した効率的なワークフローを構築し、そのワークフローを他の職種へ広げることができます。
すべてのプロジェクトメンバーがAIを活用できるようになるには、各職種がAIの利点と欠点を理解し、自分たちの業務に合った使い方を見つける必要があります。 そのためには、AIに興味を持ってもらうことが欠かせません。 日々の業務の中でAIの恩恵を実感できる状態を作ることが、継続的な学びにつながります。 また、同一職種の中でサポートし合える状態を作ることも重要です。 AI推進の負担を分散でき、より多くの人がAIを活用しやすくなります。 他職種とのコミュニケーションは重要ですが、限られた時間の中では、同じ職種の中でノウハウを共有できる方が効率的です。
これまでの取り組み
ここからは現在までの取り組みを技術的な要素も含めながら紹介します。
情報基盤を整える
AIエージェントのコンテキストに正確な情報を与えることは、AIの精度を高めるうえで重要です。 これはAIチャットボットが登場した頃から、継続的に議論されているテーマでもあります。 プロジェクト全体のAI効率化に貢献できるエンジニアを増やすには、まずチームがAIの恩恵を受けている状態を作る必要があります。
そこで、最初の目標をレビューや調査のAI化に置きました。 あわせて、セキュリティを中心としたルール整備と、情報を集約するためのツール開発をタスク化しました。
セキュリティを中心にルールを整備したのは、私たちが運用中のバックエンドチームだからです。 サービスを継続的に提供し、ユーザーの情報を守る責務があります。 AIによって大量のコードを短時間で生成できたり、少ないプロンプトで調査を完了できたりすると、強い成功体験が得られます。 ただし、その成功体験が積み重なると、リスクに対する判断が甘くなる可能性もあります。 一方で、プロンプトインジェクションによって悪意のあるコードが混入した場合、AIとの統合が進むほど影響範囲は大きくなります。 そのため、私たちのチームでは次のような原則となるルールを整備しました。
- レビューできないコードは実行しない
- AIエージェントが提案するPython、Ruby、JavaScriptといったスクリプト言語の実行は、レビューが難しい場合があるため原則として許可しない
- コンパイル言語の実行は許可するが、実行前にレビューされている状態を担保する
- 権限は個人に紐付ける
- 権限を個人に紐付けることで責任を明確にする
- 個人の権限を超えた操作を防止する
- ローカル環境はAIエージェントが動く前提とし、強い権限にはJIT昇格などを導入して権限管理を厳格にする
- 個人のシークレット管理にも2段階認証を導入し、AIエージェントがシークレットを取得することを防止する
- ワークフローは任意のリポジトリに集約する
- AIエージェントのスキルなどが、安全なツールを使う前提になっているかをレビューで担保する
- 新しい性質のツールを導入する際には都度議論する
- 読み取り専用化やサンドボックス化などの保護を全体に適用する
これらの原則があることで、データの統合を進めてもセキュリティリスクを低く保ちやすくなります。
前提が整ったので、次に情報の集約を進めました。 活用の方向性が見えていないと、集約すべき情報も曖昧になります。 そこで、定常的に発生するエラー調査やレビュー支援を最初の対象にして、必要な情報を集めました。 具体的には、ドキュメントの整備、CLIツールによるマスターデータの参照、セキュリティを担保したMCPなどを通じて情報を集約しました。 ただし、この整備でもいくつかの「現時点ではやらないこと」を決めています。
- ドキュメントの整備は網羅性よりもコアな情報を集約する
- API連携ではMCP化を必須にせず、すべてのツールを対象にすることよりも必要なツールを対象にすることを優先する
- モデルやエージェントの種類に依存したテクニックを活用しない
- 利用するツールはエージェントツールに限定せず、決定論的なツールがあれば活用する
AIエージェントへの投資が増えてから、しばらく時間が経っています。 多くのツールはできることの幅を広げることを重視しており、セキュリティの担保はベストエフォートになっていることもあります。 一方で、モデルの精度は日々向上しています。 以前のモデルでは人間がテクニックを駆使していたことも、今ではモデルが自動で対応してくれるようになっています。 それらを考慮して、私たちのチームは長く残る資産をAI活用を推進できる人材、開発基盤、長く使えるドキュメント、そしてワークフローと定義しました。 これらの原則は長期的に固定するものではなく、短期的な指針です。長期的には網羅性が重要になり、変更される可能性があります。 AI活用の初期には、現場で推進を担う人材を疲弊させず、長く価値のある資産を組織に残していくことが重要でした。
これらの原則を定義した後に最初に取り組んだのは、開発環境のマスターデータを効率的に取得するCLIツールと、基本的なコーディング規則のドキュメント整備です。 数営業日で実装とレビューを完了し、結果的に多くの調査タスクでAIエージェントが正しい回答を出せるようになりました。 AIエージェントに、人間が考える際に利用する情報と同等の情報を与えることで、正しい回答にたどり着ける可能性が高まります。
その後、仕様書も参照できるようになり、実装やレビューについてもAIエージェントが支援できるようになりました。 実装支援やレビューのように成果物を生み出すタスクでは、調査タスクよりもノイズが多くなりやすいです。 そのため、質の高い情報を与え、いかにノイズを減らしてメンバーを疲労させないかが重要でした。 こうした取り組みにより、AIの恩恵を感じ、興味を持ち、学び続けられる状態が生まれました。 結果として、AIフレンドリーなエンジニアメンバーが増えていきました。
全職種が使える環境にする
バックエンドチームの多くのタスクは、AIエージェントと一緒に進められるようになりました。 一方で、別職種のチームではまだ活用されていないケースも多くありました。 職種が違っても、同じ仕様書を読み、マスターデータなどの成果物を作る構造は共通しています。 そこで、バックエンドのリポジトリを他職種のチームにも共有することから始めました。 これにより、プロジェクトメンバーが使うAIエージェントでも、同等の情報やツールを利用できるようにしました。
前の節で定めた原則は、そのまま適用できます。 理論上は、すべての職種のメンバーが個人の権限に基づいて、エンジニアと同じようにAIエージェントを利用できるようになります。 ただし、実際には、バックエンドチーム内部でもあったように職種、メンバー間で前提知識の差があり、エンジニアが持っている前提を他職種のメンバーが持っているとは限りません。 そこで、前提の差を取り除くために、基盤とフローに対して改善を加えました。
最初に行った改善はセットアップドキュメントとセットアップコマンドの整備です。 リポジトリ内で、AIエージェントが利用するツールと開発に利用するツールを分離して整理しました。 いずれも依存を最小化し、コマンドラインで自動的にセットアップできるようにしています。 メンバーはGitHubリポジトリの権限を付与されたら、ソースコードを取得して次のコマンドを実行するだけで開発環境をセットアップできます。
sh setup.sh必要なツールのインストールやセットアップをラップすることで、誰でも同じように環境を整えられるようにしました。 副次的な効果として、チームに新しいメンバーが参加した場合のセットアップ時間も短縮されました。
次に、他職種のワークフローを自動化する際にも、私たちのチームのリポジトリにワークフローが集約されるようにしました。 より具体的には、エージェントスキルが私たちのチームのリポジトリにコミットされるようにしました。 これはプロジェクトのワークフローに意図しない脆弱な設定やコードが混入することを防ぎます。
他職種がワークフローをエージェントスキルや少量のコードに落とし込んでPRにすると、バックエンドエンジニアが自分たちのリポジトリに対する変更としてレビューします。 つまり、バックエンドチームと同じ水準のコードレビューを適用できます。 これにより、エンジニア側やプロジェクト管理側として安全性を担保できます。 同時に、他職種のメンバーも安心してワークフローの自動化を進められます。 ノイズや失敗は不安を生み、不安は活用の後退につながります。 疲労を軽減し、心理的な安全性を高められることは大きな利点です。
職種によってはGitコマンドの扱いが苦手なメンバーもいるため、いくつかのラッパースクリプトなども用意しています。 作業の複雑さを減らすことで、他職種のメンバーが自主的にワークフローの自動化を進めやすくなります。
私たちのチームのリポジトリは以下のような構成になっています。 実際の構成はもう少し複雑で、プログラミング言語由来のディレクトリも含まれますが、ここでは趣旨を伝えるために簡略化しています。
|- .agent/
| |- skills/
| | |- */
| | |- pl-*/
|- docs/
| |- coding-rules/
| |- planner/
|- cmd/
|- scripts/
| |- setup.sh
|- Makefile
|- README.md
|- SETUP.mdエージェントスキルはプロジェクトのワークフローをAIエージェント用のフローに落とし込むためのものです。
pl-* という名前のエージェントスキルや、planner という名前のドキュメントディレクトリがあります。
これは、プランナーのワークフローを言語化したものです。
同じ形で、さまざまな職種のワークフローを高い品質で言語化できます。
副次的な効果として、エンジニアメンバーは他職種のタスクへの理解を深められます。
その結果、より効果的なワークフロー自動化を提案しやすくなります。
おわりに
QualiArtsでは、現在に至るまでさまざまなプロジェクトの開発と運用を行っています。 各プロジェクトにはさまざまな職種のメンバーが関わっており、職種ごとに異なるタスクを担当しています。
プロジェクト全体でAI効率化を進めるには、AIを活用できる仲間を増やすことが重要です。 多くのプロジェクトメンバーがAIの恩恵を感じ、学びを継続することで、AIを活用できるメンバーは増えていきます。 その結果、業務の効率性や品質の向上も期待できます。 AIは発展途上であり、私たちのワークフローへの適用もまだ発展途上です。 今後も継続的に改善を行っていきます。
今回紹介した取り組みは一部ですが、この記事が関連領域の悩みを抱える開発者の方々にとって参考になれば幸いです。
