K@zuki. です。
約1ヶ月前、社内でAI開発ポリシーを策定しました。
AIを活用した開発では、速度が確実に上がってきているけど、同時にいくつかの課題も見えてきたからです。
今回は、なぜポリシーが必要だったのか、組織文化として根付かせるために何を考えたのか、そして1ヶ月経った現在の状況を共有します。
要約
- AI活用で開発速度は向上したが、同時に新たな課題も発生
- 仕組みで対応できる部分と、文化・マインドで対応すべき部分を整理
- AIを使った開発は止めるどころか、むしろ推奨
- ただし 「責任は人間が持つ」ことを明文化
- 1ヶ月経過して、以前の課題は減少傾向
AI活用が進む中で見えてきた課題
AIの活用によって開発速度は確実に向上しました。
ボイラープレートの生成、テストコードの作成、リファクタリング提案など、恩恵は計り知れません。
一方で、いくつかの課題も浮き彫りになってきました。
- 不要なファイル・処理がファイルにコミットされる
- 不完全なコードがコミットされる
- 過剰な実装や重複コードが生成される
- 意図しない副作用を持つコードが生成される
- 設計意図が不明なコードが生成される
といった問題が部分的に顕在化しつつありました。
そのためそれと対策として 「仕組み」と「文化」の2つの側面 からアプローチする必要があります。
その中でも今回は、仕組みだけでは解決できない、組織として共有すべき価値観を言語化した内容について紹介します。
AIの利用は推奨だが責任は人間
策定したポリシーの基本スタンスは明確です。
「AIは積極的に使え、ただし責任は人間が持て」
これを「人間中心の開発」という原則として定めました。
実際のポリシーの抜粋
# AIを利用した開発ポリシー
このページでは、スタディストにおけるAI（人工知能）ツールを使った開発に関するポリシーを定めます。
GitHub Copilot、Claude、ChatGPTなどのAIコード生成ツールの利用において適用されます。
## 位置づけ
AI技術の急速な発展により、開発生産性は飛躍的に向上しました。
一方で、AIが生成したコードの品質問題や、レビューの形骸化といった新たな課題も発生しています。
このポリシーは以下を目的として策定されています。
- AI活用による開発生産性の向上と、コード品質の維持を両立する
- AIを利用する開発における開発者の責任を明確化する
- セキュリティリスクや知的財産権の問題を未然に防ぐ
## 基本原則
スタディストでは、以下の原則に基づいてAIツールを活用します。
### 1. 人間中心の開発
AIは開発者を支援するツールであり、開発者の判断や責任を代替するものではありません。
AIが生成したコードであっても、最終的な判断と責任は必ず人間が持つことを前提とします。
### 2. 品質への責任
AIが生成したコードであっても、コミットする開発者が品質に対する最終責任を負います。
そのため、AIが生成したコードは必ず確認した上で使用、PRなどを行う必要があります。
### 3. 透明性の確保
AI利用時は、チームメンバーに対して透明性を保ち、必要に応じてAI利用を明示します。
自身がAIを利用して開発したが、自信がない場合は、レビュー時にその旨を伝え、チームメンバーの意見を求めます。
### 4. セキュリティとプライバシー
ツールによって利用可能な情報区分が異なるため、利用前に必ず利用可能な情報区分を整理します。
基本的には機密情報や個人情報をAIツールに入力してはいけないと考えておくと安心です。
<!- 社内向けのセキュリティ資料へのリンクなど-->
### 5. 思考の言語化
自分の考えや意図を明確に言語化することで、AIとのコミュニケーションが向上するだけでなく、チームメンバーとの相互理解も深まります。
AIのためのプロンプトや各種設計資料・コーディングルールといったドキュメントは、AIとのコミュニケーションだけでなく、チーム内のナレッジ共有や新規メンバーのオンボーディングにも役立ちます。
## 開発時のルール
### 人間中心の開発プロセス
AIツールは開発者の能力を拡張するものであり、開発者の判断を置き換えるものではありません。
AIが生成する優れたコードは積極的に活用しながら、最終的な判断と責任は必ず人間が持つことを前提とします。
### AI生成コードの利用基準
| 状況 | 対応 | 理由 |
| --- | --- | --- |
| AIが生成したコードを理解せずに使用 | `禁止` | 開発者が説明できないコードは保守できないため |
| AIが生成したコードを理解・検証した上で使用 | `推奨` | 開発効率と品質を両立できるため |
| AIに機密情報を含むコードを入力 | `禁止` | 情報漏洩リスクがあるため |
| AIを使ったアイデア出しやリファクタリング提案 | `推奨` | 創造的な活用として有効なため |
### 必須確認事項
AIが生成したコードを使用する際は、以下を必ず確認してください。
1. コードの理解と説明責任
- なぜそのコードが動くのか、チームメンバーに説明できるか
- 将来的に自分やチームがメンテナンスできるか
- AIが生成したコードの意図と実装を完全に理解しているか
2. 動作確認
- 生成されたコードが意図通りに動作することを確認する
- 空ファイルや不完全なコードがコミットされていないことを確認する
- `git status`と`git diff`で変更内容を目視確認してからコミットする
- PR作成後の差分で確認してもOK
3. セキュリティチェック
- ハードコードされた認証情報が含まれていないか
- SQLインジェクションなどの脆弱性が含まれていないか
- 適切なエラーハンドリングがされているか
4. ライセンスと著作権の確認
- 使用しているライブラリのライセンスが適切か
- コピーライトに問題がないか
- AIが既存のコードを模倣していないか確認する
## レビュー時の追加観点
レビュイー・レビュアーは、セルフチェックや通常のレビュー観点に加えて、以下の点を確認してください。
### AI特有のレビューポイント
- 過剰な実装
- 要件に対して過剰に複雑な実装になっていないか
- 例）簡単な処理に対して不必要なデザインパターンを適用している
- AIによる実装の場合、しばしば過剰な実装になることがあるため、注意が必要
- 重複コード
- 既存コードと重複する実装がないか
- AIは既存コードベースの再利用より新規生成を選びがちのため、行数が多いファイルだと同名のメソッドが複数存在することがある
- 不必要・不自然なコメント
- 英語の直訳のような不自然な日本語コメントや、あまりにも自明なコメントがないか
- 人間が書いた場合と基本的な観点は一緒だが、AIが生成したコードでは過剰にコメントが追加されることがあるため、注意が必要
- 幻覚（Hallucination）
- 存在しないAPIやライブラリを使用していないか
- 誤った使用方法になっていないか
## 推奨される活用方法
### 効果的なAI活用例
1. ペアプログラミングパートナーとして
- 設計の壁打ち相手として活用
- 実装アプローチの比較検討
- コードの問題点の早期発見
2. 開発効率の向上
- ボイラープレートコードの生成
- テストコードの雛形作成と網羅性向上
- 定型的なCRUD処理の実装
3. コード品質の改善
- リファクタリング提案の活用
- コードレビュー前のセルフチェック
- パフォーマンス改善の提案を受ける
4. 既存コードの理解と改善
- レガシーコードの動作理解
- 複雑なビジネスロジックの解説を求める
- より良い実装パターンの提案を受ける
5. ドキュメントとコミュニケーション
- コードからドキュメントの自動生成
- API仕様書の作成支援
- コミットメッセージの改善提案
6. 学習と探索
- 新しい言語やフレームワークの学習
- ベストプラクティスの調査
- エラーメッセージの解決策探索
### プロジェクトでの設定
プロジェクトごとにAI利用のガイドラインを設定できます。
必要に応じて各プロダクトにドキュメントを追加してください。
## 運用ルール
<!-- 社内向けのルールをリンク -->
## 参考資料
- [Google AI Principles](https://ai.google/principles/)
- [Microsoft Responsible AI Standard](https://www.microsoft.com/en-us/ai/responsible-ai)
- [GitHub Copilot](https://docs.github.com/copilot)
AIが生成したコードの利用基準
| 状況 | 対応 | 理由 |
|---|---|---|
| AIが生成したコードを理解せずに使用 | 禁止 | 開発者が説明できないコードは保守できないため |
| AIが生成したコードを理解・検証した上で使用 | 推奨 | 開発効率と品質を両立できるため |
| AIに機密情報を含むコードを入力 | 禁止 | 情報漏洩リスクがあるため |
| AIを使ったアイデア出しやリファクタリング提案 | 推奨 | 創造的な活用として有効なため |
シンプルですが、この基準が全ての判断の軸になっています。
このように、AIの利用は推奨しつつも、責任は人間が持つことを明確にしました。
4つのチェックポイント
AIが生成したコードを使用する際の必須確認事項を定めました。
あくまで全体的なグラウンドルールであり、各プロジェクトやチームの状況に応じて適宜調整する前提で書いているものです。
- コードの理解と説明責任
- なぜそのコードが動くのか、チームメンバーに説明できるか
- 将来的に自分やチームがメンテナンスできるか
- AIが生成したコードの意図と実装を完全に理解しているか
- 動作確認
- 生成されたコードが意図通りに動作することを確認する
- 空ファイルや不完全なコードがコミットされていないことを確認する
-
git statusとgit diffで変更内容を目視確認してからコミットする- PR作成後の差分で確認してもOK
- セキュリティチェック
- ハードコードされた認証情報が含まれていないか
- SQLインジェクションなどの脆弱性が含まれていないか
- 適切なエラーハンドリングがされているか
- ライセンスと著作権の確認
- 使用しているライブラリのライセンスが適切か
- コピーライトに問題がないか
- AIが既存のコードを模倣していないか確認する
レビュー観点の追加
通常のコードレビューに加えて、AI特有の観点を追加しました。
これらは実際にAIを使い始めてから気づいた 「AIならではの癖」への対策 です。
- 簡単な処理に不必要なデザインパターンを適用していないか
- 既存の実装を無視して新規生成していないか
- 英語の直訳や自明すぎるコメントがないか
- 存在しないAPIやライブラリを使用していないか
レビュー時には「これAIが書いたっぽいな」と感じたら、遠慮なく指摘し合う文化も大切です。
それは批判ではなく、より良いコードにするための建設的なフィードバックとして受け止めています。
思考の言語化
今回のポリシーとして、明確に定義してあるのは「思考の言語化」です。
「自分の考えを言葉にすることで、他者との共有や理解が進む」という当たり前だが難しいことを、AIを活用するにあたって意識するようにしています。
- わからないことをわからないと伝える
- 自分の考えを言葉にして認識のズレを防ぐ
組織文化として根付かせるための工夫
単に「気をつけよう」では文化は変わりません。
具体的に何を、どう気をつけるのかを言語化しておき、社内のルールとして明文化しておくことが重要です。
たとえばセキュリティについても、
- 機密情報や個人情報をAIツールに入力しないが基本
- ツールごとに利用可能な情報区分を明確化
- MCPなどの外部連携時は、連携先の情報区分も考慮
曖昧さを排除し、判断基準を明確にすることを心がけています。
また、当たり前といったことであっても、言語化し、明文化しておくことで社内の文化として根付かせることの一歩目になります。
当たり前だと思っていることでも、言語化することで共有され、組織全体の意識が高まります。
推奨している活用パターン
ポリシーでは、AIの効果的な活用方法も明示しています。
「禁止事項」だけでなく「推奨事項」を示すことで、積極的な活用を促しています。
- 設計の壁打ち相手として、実装アプローチの比較検討に
- エッジケースの発見、テストパターンの提案に
- より良い実装パターンの発見に
- コードからのドキュメント生成、API仕様書の作成に
- 新しい言語やフレームワークの学習、エラー解決の糸口に
重要なのは「AIに丸投げ」ではなく「AIと対話」し、AIをCopilot（副操縦士）として活用することです。
質問を投げかけ、提案を受け、それを批判的に検討し、最終的に自分で判断する。
このプロセスが、AIを使った開発の理想的な形だと考えています。
1ヶ月経った現在の状況
ポリシーを策定した当初は
当たり前のことしか書いてないじゃん
といった反応がちらほらありました。
これは非常に素晴らしいことだと思っています。
なぜなら、ポリシーを策定する前から、それが「当たり前」として意識されていたからです。
さて、ポリシー策定から1ヶ月、以前起きていた課題は確実に減ってきています。
むしろポリシーがあることで、安心してAIを活用できるようになってきています。
まだまだ改善の余地はありますが、ポリシーの効果を実感できています。
まとめ
AI開発ポリシーを策定して1ヶ月、狙い通りの効果が出始めています。
- 「AIが書いたから」という言い訳を許さない。
- 「自分が理解して、責任を持ってコミットする」という当たり前のことを、AI時代でも守り続ける。
この価値観を組織文化として根付かせることが、AI活用で生産性を上げながら品質を保つ秘訣だと確信しています。
みなさんの組織でも、ぜひAI開発ポリシーを作ってみてください。
仕組みだけでなく、文化として根付かせることを意識すると、より効果的です。
AIと共に、でも人間として、良いコードを書いていきましょう 🚀🤖
Discussion