自社プロダクトも活用し、AI を開発プロセスの全てに組み込む

公開日：2026.08.14

Sota Sakamoto テクニカルプロダクトマネージャー

プロダクトを方針策定から設計・実装・営業まで一気通貫で担当

はじめに

こんにちは。Acompany AI 活用推進委員会の坂本です。

Acompany では全社で AI 活用を進めており、委員会ではその実践を社内外に共有しています。今回はその一環として、社内でも AI の組み込みがとりわけ進んでいる開発の現場を紹介します。

題材は、安全な AI チャットプロダクト「Acompany セキュアチャット」の実際の開発です。開発ライフサイクルに沿って、Issue 作成 → PR 作成 → レビュー → 運用 の4段で、それぞれどのように AI を活用し、どこをまだ人間が担っているのかを具体的に解説します。

Issue 作成 — 社内ユーザーの意見から起票

Slack のフィードバックが、そのまま Issue になる

私たちのプロダクトはドッグフーディングも兼ねて社員全員に使ってもらっています。
使っていて気づいた不具合や要望は、Slack の専用チャンネルに集まってきます。

ここで動くのが、後述の「AI スタジオ」という社内サービスによって作られた vibes-securechat-fb-manager というエージェントです。
Slack に寄せられたフィードバックを拾い、既存の Issue と照らし合わせて重複を確認した上で GitHub の Issue を自動起票します。

情報が足りないときは、そのまま Slack 上でエージェント自身が

なぜ必要か
今どうなっていて、どうなってほしいか
何が満たされたらクローズしてよいか

などをヒアリングし、その結果を Issue に反映させます。

AI スタジオとは

AI スタジオは Acompany の社内プロダクトで、一言でいえば 「誰でも簡単に AI エージェントを作って Slack に生やせる」 ツールです。セキュリティを担保するための工夫も多く盛り込まれているのですが、ここでは割愛して、使い勝手（UX）の部分だけ紹介します。

チャットのような UI で、会話しながらエージェントを作れます。私たちはこの「雰囲気だけでサッと作れる」感じを vibe-coding になぞらえて、社内では作ったエージェントを vibes（バイブス）と呼んでいます。
Notion / freee / Slack など各種サービスと MCP で連携できます。権限は「そのエージェントを呼び出した人」のものが使われるので、freee MCP を繋げることで自分の給与情報を他人に勝手に見られる、といった心配はありません。今回紹介する事例では GitHub を繋げることで開発に活用しています。
人間に依頼するのと同じ感じで Slack でメンションをつけるだけで依頼ができるため、誰でも簡単かつ直感的に利用することができます。
挙動を変えたいときも Slack で直接 FB ができます。例えば「次から箇条書きで伝えてほしい」「毎週月曜の朝 9 時にこのリポジトリの進捗をこのチャンネルに投稿してほしい」と伝えるだけで次回以降の挙動に反映されます。コードを直して再デプロイして、といった手間が発生しません。

この「導入と変更の簡単さ」により弊社の至るところで AI 活用が進んでおり、その一例として今回は Issue 作成を紹介しました。開発領域に限っても、フィードバックの取りこぼしがないかの確認や、変更内容を非エンジニアにも分かりやすく伝えるリリースノート作成補助、現在のプロダクトの仕様確認など他にもさまざまなタスクを AI エージェントに行わせています。

同じく AI 活用推進委員会の末竹さんが書いた以下の記事で、AI スタジオの UI やユースケースがより詳細に紹介されておりますので、興味のある方はぜひこちらもお読みください。

AIプロダクトを作る会社は、社内でAIをどう活用しているのか | アカンブログ(Acompany公式ブログ)

アカンブログは、複雑な課題を社会の中で信頼して使える形に変えていく、Acompanyの思考と現場が見えるメディアです。

アカンブログ

役割の切り分け

Issue 作成の画像でも分かるように、フィードバックを出した人が必ずしもそのまま AI エージェントに指示を渡しているわけではありません。
開発者（エンジニア）は、直接 AI エージェントに話しかけますが、それ以外の人は、まず普通にチャンネルへ書き込むようにしており、開発者がその投稿に返信する形で AI エージェントに Issue 作成依頼を出すようにしています。
この際、フィードバック投稿者の意図を深掘りしたい時は AI エージェントに依頼する前に投稿者に対して聞き取りから始めることもあります。
AI エージェントはスレッド全体を読むことが出来るため、聞き取りが完了した段階で AI エージェントに依頼すれば、そこで決まった内容がそのまま Issue に反映されます。

フィードバック投稿者が直接 AI エージェントと会話するフローにしていない理由は、現段階では意思決定は人間（開発者）の役割にしているからです。
「そのフィードバックを取り込むか」「取り込むならどんな仕様にするか」という判断はまだ開発者が握りたいため、開発者以外の人が直接 Issue を作成するフローはまだ作らずにいます。

この役割の切り分けに関しては、今後 AI の性能が進化して仕様の意思決定まで任せられるとこちらが判断出来るようになれば、AI に任せる範囲をより広げていくと思います。

この記事の他のステップにも言えることですが、AI の性能が日進月歩で進化している昨今では、その性能に応じて AI に任せる責務範囲と人間が手を動かす範囲を都度適切に切り分けることが非常に大事だと考えています。

PR 作成 — 難易度で人間の関与を切り替える

Issue ができたら、次は実装です。ここからは Claude / Claude Code の出番になります。ポイントは、Issue の難易度によって人間の関わり方を変えていることです。

簡単な Issue は、Claude が自動で PR を作る

軽微なバグ修正や小さな改善は AI に自動でやらせることにしています。
Issue に bug や size/S などのラベルが付くと、GitHub Actions 上で Claude Code が自動発火します。
Claude Code が実装し、Pull Request を自動で作成し、レビュアーをアサインして、Slack に通知するところまでを一気に行います。

この自動 PR 作成 CI の質を担保するため、内部でさまざまな工夫をしております。例えば、実装役・複数のレビュー役・反論役を用意し「実装 → レビュー → 修正」の改善ループを Claude Code が内部で回し、品質を上げてから PR を出させるようにしています。

難しい Issue は、仕様の議論に人間が入る

一方で、仕様がまだ固まっていない変更や影響範囲の大きい Issue をいきなり AI に実装させても満足いく精度のものはまだまだ出来ずトークンも過剰に消費してしまうため、こういった場合は仕様策定の部分を人間と AI が共同で行うところから始めるようにしています。

セキュアチャットチームでは現在 openspec というライブラリを使っています。
openspec は Claude Code などのコーディングエージェントにスキルの形で入れるだけで仕様書駆動開発が非常にスムーズになるツールです。
仕様書はおおまかな提案書、具体的なタスク、技術的な設計上の決定など人間が理解しやすい粒度に分割された形で毎回同じ形式で出力されるため、簡単にレビューすることが出来るようになっています。

そして、この仕様書をつくる部分は必ずAI と人間が議論しながら進めるようにし、最終的な仕様書は必ず人間がレビューするようにしています。影響が大きい変更の場合は、仕様書が固まった時点でいったん PR を作成し、他のメンバーにレビューしてもらうこともあります。実装に入る前に仕様のレビューを挟むことで、大きな後戻りを防げます。

仕様が固まったら、あとの実装は Claude Code に委ねます。
ここで実装を完全に委ねられるように、仕様書策定の部分で openspec を用いて隅々まで決めておくことが重要になります。

レビュー — 複数の AI エージェントが並列でレビューする

PR ができたら、次はレビューです。ここは Claude Code のデフォルトのレビュー用スキルを参考にしつつ、そのうえでセキュリティ項目など本プロダクト独自のレビュー観点などを加えたオリジナルスキルを作成しています。

レビュースキルを実行すると、初めにオーケストレーター（司令塔）エージェントが立ち上がり、変更差分と PR の意図を読み取ります。そのうえで、変更内容に応じて専門レビュアーエージェントを並列に起動します。

常に起動するレビュアー: セキュリティ / アーキテクチャ / パフォーマンス
変更内容に応じて起動するレビュアー: バックエンド / フロントエンド / UX / データベース / テスト / API 契約 / インフラ / TEE（本プロダクト特有の、機密計算環境まわりの観点）など

そして最後に、Devil's Advocate（反論役） エージェントが登場します。他のレビュアーが挙げた指摘をあえて批判的に見直す役割で、AI は自分の出力内容を疑うのが苦手な特性上、指摘の検証をコンテキストを分けた別エージェントに行わせることでレビューの質が一気に上がります。

最終的な指摘は重大度（CRITICAL から NITPICK まで）を付けて整理された状態で、修正実装例まで含めた形で出力されます。このレビューは PR が開かれたタイミングで CI から自動で走るため、人間は最初からAIが検出可能なバグが全て検出済みの状態からレビューすることが出来ます。

運用 — アラートから、無人で原因解析と修正パッチまで

最後に運用です。この工程では、アラートが鳴ってから人間が最初に画面を開くまでの間に、一次対応が終わっている状態を作っています。

監視基盤がアラートを出力すると、人間の対話を一切挟まずに次が進みます。

アラート名に対応する手順書（Runbook）を引き、ログを分析して原因を絞り込む
確信度つきの診断結果を Slack に通知し、Issue として残す
原因が特定できたものは、修正パッチの提案まで出す

診断結果には確信度（high / medium / low）が付き、「調べ尽くす前に安易に low にしない」といったルールで精度を保っています。確信度が低いときは、残った仮説と引き継ぎ手順まで書き添えて人間に渡します。

つまり人間の最初の仕事は「一次対応を始めること」ではなく、AI が出した原因と修正案を見て採否を判断することになっています。

これを実現するために作ったのが app-insights-diagnose という Claude Code のカスタムスキルです。Azure Application Insights のログ（トレース・例外・リクエスト・依存関係）を KQL で分析し、原因の特定と修正案の提示までを行うスキルで、アラートを起点にこのスキルが発火するようになっています。

さらにこのスキルは /diagnose 500エラーが増えている のように対話モードとして手動で呼び出すこともできます。この対話モードには、私たちが積み上げてきた診断の手順が型として埋め込まれています。

まずはユーザーの申告（モデル名や時刻）を信じて探し、見つからなければ段階的に範囲を広げる。
異常を探す前に「そもそもこれが仕様通りの正常な動作ではないか」を先に判断する。
閾値を決め打ちせず、直近 7 日間の分布からベースラインを動的に取得して逸脱を見る。
「使っているモデルの勘違い」「処理が重いのとエラーの混同」といった、人間が陥りがちな思い込みのパターンをあらかじめ織り込んでおく。

基本的な障害対応知識に加えて過去の障害対応で溜まったプロダクト固有の知見まで持ち合わせた AI と伴走することで、アラートには現れない違和感などを誰でも簡単に調査することが出来ます。

また、そもそもアラートルールが必ずしも全ての問題を網羅出来ているとは限らないため、定期的に Claude が監視基盤を閲覧し、異常事態が起きてないかを非決定的に検出するワークフローも並列で走らせています。

まとめ

開発ライフサイクルに沿って、私たちの AI 活用を4段で紹介してきました。最後に、それら全体を通して私たちがどのように AI 活用と向き合っているかを簡単にまとめます。

1．定型的な作業や一次対応など簡単なタスクは AI 側に完全に任せる。

Slack の FB からの Issue 起票、簡単な Issue の PR 化、レビューでの一次検出、アラートの原因解析など、定型作業に近いタスクは出来る限り AI に委譲しています。

2．大掛かりな仕様策定や重要な意思決定など難しいタスクは人間が適宜確認をする。

フィードバックを取り込むか、どんな仕様にするかなど、明確な正解がなく高度な判断が必要なタスクには依然として人間がレビューを行うようにしています。ただし人間が全てを行うのではなく、手を動かすのは出来る限り AI に任せながら要所だけを人間が確認するようにし、なるべく人間がボトルネックにならないようにしています。

3．線引きを都度見直す。

簡単なタスクは AI に完全に任せ、難しいタスクは人間が間に入ると書きましたが、簡単と難しいの境界線は AI の性能次第です。AI の性能は日進月歩で上がり続けているため、一度引いた線を守り続けるのではなく、AI の進化に合わせて線そのものを定期的に引き直し続けることが、いまいちばん大事だと考えています。