著作権・公序良俗リスクをAIで自動判定するSlack絵文字チェッカーを作ってみた
はじめに
こんにちは、ドコモ・テクノロジの神崎 由紀です。私たちの会社はNTTドコモの機能分担子会社です。私はNTTドコモのクラウドCoEチームのメンバーとして、ドコモグループ全体のクラウド活用を推進する業務に携わっています。
現在、ドコモグループ内でもGitHub Copilotの利用者が急増しており、AIをパートナーとした開発スタイルが定着しつつあります。以前ドコモ開発者ブログで書いたGitHub Copilotに関する記事はこちらです。
- 開発の内製化を加速すること
- 主体的にプロジェクトをリードできるエンジニアを増やすこと
これが、AI活用推進の根底にある狙いです。内製化のハードルを下げ、日常の開発をAIが支援することで、組織全体の生産性を底上げしたい。そのために、私たちは GitHub Copilot や Amazon Q Developerといった最新ツールの検証を続けています。
本記事では、Amazon Q DeveloperのIDE環境であるKiro IDEを用いて、仕様策定から実装までを一気通貫で行う仕様駆動開発（Spec-Driven Development）を実践した内容を紹介します。
背景
生成AIによる開発支援が進む中で、チャットで「いい感じに作って」と頼む直感的なスタイル（いわゆる Vibe Coding）が流行していました。プロトタイプ開発には向いていますが、エンタープライズ開発においては、仕様の認識齟齬や手戻りが課題となりがちです。
- AIと人間の仕様認識のズレ
- 実装後の手戻り
- 結合時の不整合（API・スキーマ・設定など）
こうした課題に対し、まず仕様を明確化し、その仕様を基準にAIに実装を任せる仕様駆動開発が注目されています。ドコモのような大規模組織では、この手法とAIの組み合わせが非常に相性が良いと感じています。
Kiro IDEの紹介
ここで、今回紹介するKiro IDEについて簡単に触れておきます。
Kiro IDEは、AWSが開発したAIネイティブな統合開発環境（IDE）です。VS Codeをベースとしており、従来のチャットでコードを書く機能に加え、AIエージェントが自律的に開発プロセスを進める機能を備えているのが最大の特徴です。
Kiroには大きく2つのモードがあります。
- Vibeモード: チャットで対話しながら直感的にコードを書く、プロトタイプ向けのモード
- Specモード: 要件定義から実装までをドキュメントベースで進める、エンジニアリング重視のモード
本記事では、後者のSpecモードを活用し、AIと対話して仕様を詰めながら進める、確実な開発を実践します。
検証テーマ
今回の題材に選んだのは、Slackのカスタム絵文字画像から、以下のリスクを判定するシステムです。
- 著作権侵害の可能性
- 公序良俗に反する可能性
アーキテクチャは次の通り、シンプルなAWSサーバーレス構成を採用しました。
- フロントエンド：React
- バックエンド：AWS Lambda（Python 3.13）
- モデル推論：Amazon Bedrock（Claude 3.5 Sonnet）
- API管理：API Gateway
このシステムを、Kiro IDEのSpecモードを使い、次の流れで構築しました。
- 要件定義（requirements.md）
- 設計（design.md）
- 実装計画（task.md）
- 実装（Implementation）
Step 1）1行の指示から始まる仕様策定
開発のスタートは、Kiroに対して一行の指示を投げることから始まりました。
私のプロンプト
「企業Slackのカスタム絵文字を自動チェックするシステムです。知的財産権や公序良俗の違反を検出したいです。」
これだけで、KiroはEARS形式に則った高品質なrequirements.mdを提示してきました。
ただし、そのまま採用するのではなく、現実的な制約や優先度に合わせてAIと対話しながら修正していきます。
実際の対話の流れ
| 項目 | Kiroの提案 | 私の判断（修正指示） | 結果 |
|---|---|---|---|
| スコープの調整 | 要件7: Slack APIと統合してリアルタイム検知を行う | フェーズ1ではコストを抑えたい。CSVファイルアップロード機能に絞る。 | Slack連携を削除し、CSV一括チェック機能に変更 |
| データ形式の厳密化 | - | CSV形式はヘッダーなし、1列目 絵文字名、2列目 画像URLで固定 | 要件7としてCSV形式の受入基準が明確化 |
| UI/UX | - | 最低限表示したいカラム「画像（プレビュー）」「絵文字名」「IPリスク判定」「公序良俗リスク判定」「判定理由」「信頼度スコア」 | 要件8としてUI表示項目が詳細に追加 |
このように、AIが作った土台に対し、人間が詳細条件や制約を調整していくことで、曖昧さがなく、かつ自分たちの業務にフィットした要件定義書（requirements.md）が完成しました。
対話の結果、最終的に確定したrequirements.mdの一部がこちらです。
このように対話することで、AIが提示した仕様を、自分のプロジェクトの制約や現実に即した仕様へと調整していきました。 ゼロからこの仕様書を書くのは骨が折れますが、たたき台を修正するだけなので、効率的に、かつ高品質に要件を固めることができました。
Step 2）Specモードによる設計ドキュメント（design.md）の生成
要件定義書（requirements.md） が固まれば、確定した要件をベースに、「設計」→「実装計画」とドキュメントを積み上げていき、最後に実装を行います。
対話を通じて要件定義書の内容が固まったら、次のフェーズへ進みます。 操作はシンプルで、画面上に表示されている 「Move to design phase」 ボタンをクリックするだけです。
ボタンを押すと、Kiroは確定した要件定義書を入力として、基本設計書 （design.md）の生成を開始します。数分待つと最初の設計書が提案されました。
ご覧の通り、内容は非常に充実していますが、アーキテクチャ（Backend層）を見ると 「Node.js + Express」 が提案されています。今回、私が考えていた運用コストを抑えたAWSサーバーレス構成とは異なります。 ここで、以下の修正指示を出しました。
入力したプロンプト
フェーズ1ではバックエンドはAWS Lambda （Python 3.13）で実装します。 バックエンドにDBや複雑な非同期処理やキューイングシステムは不要です。フロントエンドがパースした行を直列で処理します。 LambdaにはAPIキーを持たせず、IAMロールを付与してBedrockへのアクセス権を管理してください。
この指示には、3つの意図があります。
- 技術スタックの指定
Python 3.13とLambda を明示し、環境を固定する。 - 複雑性の排除
DBやキューは不要、フロントエンドでの直列処理と指示することで、シンプルな構成にする。 - セキュティ
APIキー管理のリスクを排除するため、IAMロールによる認証を採用する。
私のプロンプトを受け取ると、Kiroはdesign.md を書き換え、以下の更新結果を提示してきました。
Kiroの応答（設計書更新結果）
設計書を更新しました。主な変更点：
- バックエンド： AWS Lambda (Python 3.13) に変更
- AI API： Amazon Bedrock (Claude 3 Sonnet)
- 認証： IAMロールによるBedrockアクセス（APIキー不要）
- 処理フロー： フロントエンドでCSVをパースし、各絵文字を直列でLambdaに送信
- インフラ： API Gateway, CloudWatch, IAMロールの追加
確定した設計書は、単なる構成図だけでなく、品質担保のための定義まで含まれた非常に密度が高いものでした。 特に重要な3つのポイントを抜粋して紹介します。
- アーキテクチャとデータフロー
私が指示した「フロントエンドからの直列処理」という制約が、Mermaid記法のシーケンス図として正確に視覚化されています。Lambdaがステートレスに振る舞い、フロントエンドがループ処理の制御を担う構造が一目でわかります。
アーキテクチャとデータフロー - 正確性プロパティ
どう動くべきかという仕様が、検証可能なプロパティ（特性）として定義されています。これは後の工程で、AIが自動生成するテストコードの基準となります。
正確性プロパティ - Bedrockへのプロンプト設計
AIの判定ロジックも、日本語のプロンプトとして設計書に含まれていました。知的財産権侵害の基準が明確に言語化されており、ブラックボックスになりがちな部分を把握できます。
Bedrockプロンプト設計
このように、アーキテクチャからプロンプトに至るまで、実装に必要な設計が細かく定義されています。
Step 3）実装計画（task.md）
設計書のチューニングが完了すると、画面上の「Move to implementation plan」ボタンをクリックし、次のステップへ移行します。
Kiroは確定した設計書（design.md）を入力として、実装タスクリストの生成を開始します。
提示された計画を見て驚いたのは、網羅性です。 単なる機能実装だけではなく、品質担保のためのタスクがあらかじめ組み込まれていました。
生成されたタスクリストを見て気づいた点が2つあります。
- 要件との完全な紐付け
各タスクの下に Requirements: 1.1 といった参照が付いています。これにより、各タスクが、どの要件定義に基づいているかが明確になっています。 - 品質タスクの提案と判断
リストには、機能実装だけでなくプロパティテスト（ランダム入力検証）やユニットテストなどの検証タスクも自動的に含まれていました。今回はプロトタイプなので、スピードを優先してコア機能の実装に集中しましたが、本番開発であればこれらのテスト実装もAIに任せることで、高品質なシステムを構築できると感じました。
Step 4）実装（Implementation）
3つのドキュメント（要件・設計・計画）が揃ったら、実装フェーズです。計画に問題がなければ、画面上の「Start task」をクリックするだけで、Kiroのエージェント機能がtask.mdの上から順にタスクを実行し始めます。
実装の開始は簡単です。計画に問題がなければ、画面上の「Start task」をクリックするだけです。
画面上では、ファイルが次々と生成され、ターミナルでコマンドが走る様子がリアルタイムで流れていきます。
開発者は、AIが作成するファイルや実行されるコマンドを確認し、承認ボタンを押すことで実装が進んでいきます。
途中、ライブラリの相性問題によるビルドエラーがなどが発生しましたが、エラーが表示されると、Kiroは「エラーが発生しました。以下の修正を行いますか？」と、自己修復を提案してきます。
動作確認
実装計画を完遂し、ローカルでフロントエンドを起動、デプロイ済みのバックエンドのLambdaと接続し、動作確認を行いました。
ローカルで稼働したフロントエンド（React）の画面がこちらです。
CSVファイルをアップロードし、デプロイ済みのAWS Lambda関数（API Gateway経由） へリクエストを送信したところ、接続エラーなく一発でAPI連携に成功しました。
Vibe Codingとの大きな違い
APIのURLやリクエスト/レスポンスのJSONスキーマ、CORS設定など、Vibe Codingなら時間を取られがちな結合部分で、一切のトラブルが発生しませんでした。
これは、requirements.mdとdesign.mdで仕様を定義し、AIに実装させた、仕様駆動開発の効果を表しています。
そして、AWS上で稼働するLambda（Python）側では、計画通りにAmazon Bedrockの Claude 3.5 Sonnetモデルを使って判定処理が実行されています。 一方で、AI判定の精度については改善余地があり、プロンプト調整が必要でした。
以前、Google環境でプロトタイプを作成した際はGemini 2.5 Flashを利用しましたが、今回はAWS環境で実装したため、親和性の高いAmazon Bedrock（Claude 3.5 Sonnet）を選定しています。
モデルによって得意な表現や認識特性は異なりますが、後からモデルを変更したり、プロンプトだけを集中して改善したりすることも容易な設計となっています。後から試行錯誤しやすい設計になっている点も、仕様駆動開発のメリットだと言えます。
まとめ
今回の検証を通じて、AIを活用した開発スタイルには、適材適所があることを実感しました。
| 手法 | 優先事項 | 向き/不向き |
|---|---|---|
| Vibe Coding | スピード | プロトタイプ向き |
| 仕様駆動開発 | 品質 | エンタープライズ向き |
ドコモのようなエンタープライズ開発において、AI活用を推進する上で、後者の仕様駆動開発と相性が良いのではと考えています。
このアプローチは、外注資産の内製化における仕様の明確化を助け、内製化のハードルを下げつつ品質を担保する、有力な選択肢になり得ると感じました。エンジニアの役割は、AIと一緒にコードを作るだけではなく、要件を詰め、設計を判断し、指示書を渡すことへとシフトしていると感じました。
今後の展望
- GitHub CopilotのPlanモードなど、他プロダクトの仕様支援機能との比較検証
- Kiro IDEの高度機能（Agent Hooks / Steering）の活用
AI開発ツールは日々進化しており、これらの手法を継続的に検証しながら、組織全体でのAI活用レベルをさらに高めていきたいと考えています。
