📖 3分で読める要約
🎯 何を実現したか
- 3ヶ月で個人実験→チーム標準化：AI×ナレッジベースによる組織力向上
- 具体的成果：新メンバーオンボーディング期間1/3短縮、複雑タスクの2日完了
- 文化変革：全職種（PM/QA/エンジニア）でチーム全員AIフレンドリーな環境を実現
🗓️ 本記事で扱う範囲（前編）
- Phase 1（3月）：個人実験でCline+ナレッジベース構築、週次ペアプロ開始
- Phase 2（4-5月）：Cursor移行、教育プログラム、MCP活用本格化
💡 成功の核心
- 知識循環の仕組み化：タスク完了時のナレッジベース更新を作業の一部に
- 推進者の継続投入：通常業務と並行したAI活用の実践と知識共有
- 全員が生産者文化：受け手から発信者への転換
🎁 読者への価値
模倣可能な「効率化」を超えた、複利的に成長する「組織力」構築の具体的ロードマップ
*最近入った栗ちゃんがこんな感じで書いてくれました。
この開発者体験を実現した裏舞台のお話です💡
是非ハートを押してこの記事に戻ってきてください👍
👋 自己紹介
はじめまして、Chenです。2025年3月に現在の会社にジョインし、現在は在宅事業本部（toB）のリードエンジニアを務めています。
入社直後からメインタスクと並行して「AI×ナレッジベースによる組織力向上」の実験を開始し、3ヶ月でチーム標準化を実現した取り組みの当事者として、リアルな実践プロセスをお伝えします。
はじめに
「AIツールを導入したけど、結局は個人の効率化止まり」
「他社も同じツール使ってるのに、なぜか効果に差が出る」
「AIにタスクを任せたいけど、結局人間が確認・修正で手間が増える」
そんな悩みを抱えている方も多いのではないでしょうか？
本記事では、個人の実験から始まって3ヶ月でチーム標準になった、AI×ナレッジベース活用の実践プロセスを詳細にお伝えします。
単なる「効率化ツール導入」を超えた、
使えば使うほど組織全体が強くなる仕組み作り
の具体的ロードマップです。
先日、AWS主催の「Coding Agent at Loft #2 ～ AIコーディング活用事例Night」にて、「ナレッジベースで実現するAIとの効果的な協働」というテーマで登壇させていただきました（発表資料）。発表では理論的な話が中心でしたが、実はこの取り組みは私が3月に現在の会社に入社してから、リアルタイムで進めてきた実践の集大成でもあります。
今回は発表では触れられなかった裏舞台や具体的な実装、そして何より「個人の実験がいかにしてチーム標準になったか」の生々しいプロセスをお伝えしたいと思います。
※本記事では、セキュリティ上の観点から、実際のシステム名、ログイン情報、個人名、企業名等はマスキングされています。
🗺️ 全体ロードマップ
以下は3ヶ月間の取り組み全体の流れです。本記事（前編）ではPhase 1-2までを詳しく解説します：
Phase 1: 個人実験期（3月）- 「模倣可能な効率化」からの脱却
📌 Phase 1のキーポイント
- 時期：3月（入社直後）
- 目標：個人レベルでのAI×ナレッジベース活用基盤構築
- 成果：Cline+rules/doc構築、週次ペアプロ開始
- 重要な学び：理解した内容を必ずナレッジベースに落とし込む習慣化
3月初旬：Cline + rules/doc構築の開始
入社直後、既存のコードベースを理解するために通常なら先輩エンジニアに質問攻めになるところですが、私は違うアプローチを取りました。
まず、リポジトリ内に以下の構造を作成：
project-root/
├── doc/ # メインのナレッジベース
│ ├── README.md
│ ├── architecture/ # システムアーキテクチャ
│ │ ├── overview.md
│ │ ├── data_models/ # データモデル詳細
│ │ └── integrations/ # 外部システム連携
│ └── development/ # 開発ガイドライン
│ ├── setup.md
│ ├── workflow.md
│ └── coding_standards/
│
└── .clinerules/ # Cline用AI協働ルール定義
├── 01-project-overview.md
├── 02-architecture.md
├── 03-coding-standards.md
├── 04-backend-guidelines.md
├── 05-frontend-guidelines.md
├── 06-testing-strategy.md
├── 07-git-workflow.md
├── 08-project-structure.md
└── 09-troubleshooting.md
この時点ではClineを使用し、コードを読み解きながら同時にドキュメントを生成していく手法を確立しました。重要だったのは、**「理解した内容を必ずナレッジベースに落とし込む」**という習慣化です。
3月中旬：起案書作成と仮説立て
個人レベルでの手応えを感じたため、チーム展開の起案書を作成しました。この起案書では、3段階の発展戦略を定義：
第一段階：開発者のみのAI活用（現在実現済み）
- Cursor + MCPによる個人効率化
- ナレッジベースの構築と活用
- チーム内でのAI協働文化の定着
第二段階：上流から下流まで全工程の連携（現在一部実現済み）
- PdMの起案から仕様書作成、チケット作成、開発、QA、リリースまでを統合
- 事業レベルでのKnowledge構築と活用
- PM、QA、デザイナー等（みんな技術者）も含めたAI協働エコシステム
第三段階：全体開発フローの自動化連携
- ナレッジベースだけでなく実装・テスト・デプロイを含めた開発プロセス全体の自動化
- PdM、エンジニア、QAの完全連携による80%の作業自動化実現（したい）
- 技術基盤：RemoteMCPの活用検討
核心となる仮説：
- AIによる知識循環の加速：認知限界を超えた情報処理
- ナレッジベースによる組織知の基盤強化：「私たちならではの方法」の継承
- 長期的な競争優位性：複利効果のある知識資産形成
- 全員が生産者: 皆が消費者だけでなくナレッジの生産者でもある文化の構築
この起案書以降の全ての実践は、これらの仮説を段階的に検証していく取り組みとして位置づけられます。
3月下旬：週次AIペアプロ開始
チームメンバーとの週次AIペアプログラミングセッションを開始。ここで重要だったのは、ただのツール紹介ではなく、知識共有の場として設計したことです。
毎回のセッションで：
- 新しいAI活用パターンの共有
- 失敗事例の振り返り
- ナレッジベース構造の改善議論
この時期の学び：AI協働の実践フレームワーク
マインドセット：
- AI使用への躊躇は不要：時代に流されたくないなら、今更使っていない方が恥ずかしい
- 人間の役割の変化：課題整理と伝える能力が重要になる
AI利用の7段階フレームワーク：
1. Planning（計画）
- 目標設定：達成したい目標と成功基準を明確に定義
- 情報収集：AIに提供すべき背景情報、制約条件、参照資料を特定
- 出力設計：期待する出力の形式、詳細度、構造を決定
- 評価基準：成果物を評価するための具体的な基準を設定
2. Implementation（強化）
- プロンプト設計：効果的なプロンプトを作成し、必要なコンテキストを提供（※具体例は後編で詳述）
- 対話的改善：AIの初期出力に対してフィードバックを行い、専門知識と組み合わせて改善
- 反復的洗練：複数の選択肢や観点を検討し、段階的に質を高める
- 共同創造：自分のアイデアとAIの提案を統合
3. Action（実行）
- 実装指示：確定した方針に基づき、具体的な作業をAIに依頼
- 分割統治：複雑なタスクを小さな部分に分割し、段階的に実装
- 進捗確認：作業の進行状況を定期的に確認し、方向性を調整
4. Check（検証）
- 品質評価：生成された成果物の品質、完全性、正確性を詳細に確認
- 不整合検出：論理的矛盾、事実誤認、技術的問題点を特定
- フィードバックループ：問題発見時は具体的な修正指示と共に実装段階に戻る
5. Test（テスト）
- 機能検証：実際の環境での動作確認や機能テストを実施
- 継続的改善：テスト過程で発見された問題の修正
6. Summary（総括）
- ドキュメント化：
doc/に適切に記録 - 知見の抽出：仕様やノウハウを形式知化
- 成果共有：関係者や組織内での知識共有を促進
7. Reflection（振り返り）
- 効率分析：AIとの協業により得られた時間・リソースの節約を評価
- 学習ポイント：プロセスから学んだ知識や次回に活かせるポイントを整理
- スキルギャップ：AIを最大限活用するために自身も進化
実践上の成功・失敗パターン：
成功パターン：
- タスク完了時に必ず
implementation.mdを作成 - 問題解決プロセスを自動記録化
- AIが理解しやすい形での構造化
失敗パターン：
- 完璧を求めすぎて更新が止まる
- AIプロンプトの属人化
- チーム共有を見据えない個人最適化
Phase 2: チーム展開期（4-5月）- 「組織力」への転換点
📌 Phase 2のキーポイント
- 期間：4-5月
- 目標：個人成果のチーム展開と標準化
- 成果：Cursor移行、教育プログラム開始、MCP活用本格化
- 重要な学び：全職種でのAI協働文化とチーム全体による自発的ナレッジベースに貢献
4月初旬：PM・エンジニア両軸の教育プログラムとテンプレート化
チーム全体でのAI活用を目指し、通常業務と並行した実践的なアプローチを開始しました：
📊 AI活用実践の取り組み
- PM/PdM向けAI活用：通常業務での実践と知識共有
- 開発者向けAI活用：コーディング業務での実践と知識共有
- 実践期間：通常業務と並行して継続
最初は僕が一人で教えていましたが、今ではチームメンバーが発表者を担当するようになりました。みんなが教わる側から教える側になったことで、より深い学習と知識共有が実現できています。
重要な成果：上流からQAまでの全工程AI協働文化
- PM段階：要件整理、仕様書作成、リスク洗い出し
- 開発段階：ナレッジベース参照コード生成、自動ドキュメント更新
- QA段階：過去事例活用、テストケース生成、要注意ポイント特定
特に嬉しかったのは、QAチームが「これ他でも使えそう」「この不具合パターンもナレッジベースに入れよう」と、自発的にナレッジ蓄積を考えてくれるようになったことです。
AIが理解しやすい書式の整備
AIがプロジェクトの文脈を掴めるよう、もろもろテンプレートを標準化しました。
例えばJira：
実際のタスク例：
## サマリ
[動詞] [簡潔なタスク内容]
## 説明
### 背景
[関連ストーリーがない場合、このタスクが必要となった背景や理由]
### 作業内容
[詳細な作業ステップ]
### 技術的詳細
*エンジニア側補足で良い
- [使用する技術、メソッド、クラスなど]
- [参照すべきコード箇所]
## 完了条件
- [ ] [具体的な完了条件1]
- [ ] [具体的な完了条件2]
## 依存関係
- [このタスクの前に完了すべきタスク]
- [このタスクと並行して行われるタスク]
## 関連ドキュメント
- [アーキテクチャ図](./doc/architecture/...)
- [実装ガイド](./doc/development/...)
この構造化により、AIが文脈を正確に理解し、適切な実装支援を行えるようになりました。
4月中旬：Cline→Cursor移行とチームRule整備
全職種統一のため、Cursorへの移行を決定しました。エンジニアだけでなく、PdMやQAまで含めた全員がCursorを使用する体制を構築。移行の主な理由は：
コスト効率性：
- Clineの従量課金からCursorのサブスクリプションモデルへ
- チーム全体での月額コストが実質半分以下に
- 使用量を気にせずAIを活用できる心理的安全性
統一した体験：
- メンバー間でのツール・プロンプト・ワークフローの標準化
- 個人設定の属人化から脱却し、チーム共通のベストプラクティスを確立
- オンボーディング時の学習コスト大幅削減
技術的先進性：
- Cursorは同領域において最も先進的なポジションを確立
- Composer機能による複数ファイル同時編集
- MCPサポートへの早期対応
- VSCode互換性による既存エクステンションとの親和性
この移行時に、個人レベルで蓄積したナレッジを元に、体系的なCursorルールを整備しました。重要だったのは、AIがナレッジベースメンテナンスも行えるよう設計したことです。
特筆すべきは、この段階でチーム全体が自発的に貢献するようになったことです。例えば、宮田さんがreview-knowledge-maintenance/やworkflow/ディレクトリのルールを積極的に追加・改善してくれるなど、もはや一人の取り組みではなく、チーム全体でナレッジベースを育てる文化が定着しました。
以下の19個の.mdcファイルとサブディレクトリで構成：
.cursor/
├── mcp.json # MCP設定
└── rules/
├── 00-rules-overview.mdc # ルール概要
├── 01-project-overview.mdc # プロジェクト概要
├── 02-architecture.mdc # アーキテクチャ
├── 03-coding-standards.mdc # コーディング規約
├── 04-backend-guidelines.mdc # バックエンドガイドライン
├── 05-frontend-guidelines.mdc # フロントエンドガイドライン
├── 06-testing-strategy.mdc # テスト戦略
├── 07-git-workflow.mdc # Gitワークフロー
├── 08-project-structure.mdc # プロジェクト構造
├── 09-troubleshooting.mdc # トラブルシューティング
├── 10-ai-documentation-automation.mdc # AIドキュメント自動化
├── 11-coding-standards-backend.mdc # バックエンドコーディング規約
├── 12-coding-standards-frontend.mdc # フロントエンドコーディング規約
├── 13-code-review.mdc # コードレビュー
├── experimental/ # 実験的機能
│ └── gccj/ # 個人実験用
├── review-knowledge-maintenance/ # レビューナレッジ管理
│ ├── 01-update-review-knowledge-overview.mdc
│ └── 02-create-pr-review-knowledge.mdc
└── workflow/ # ワークフロー自動化
├── 10-start-jira-ticket.mdc
└── 40-production-backport-into-dev.mdc
Rule運用フローの確立
この時期に確立したRule運用フローも、チーム展開の成功要因の一つでした：
ディレクトリ構造：
.cursor/
├── rules/ # 本番環境のルール
│ ├── 00-rules-overview.mdc
│ ├── 01-project-overview.mdc
│ ├──...
│ └── experimental/ # 実験用ルール (gitignoreで除外)
│ ├── gccj/ # 個人実験用
│ └── ...
ワークフロー：
-
個人実験フェーズ：
.cursor/rules/experimental/で個人的にルールをテスト - レビューと承認フェーズ：効果的なルールをPRでチーム共有（通常開発と分離）
- 適用フェーズ：マージ後、チーム全体への通知と効果測定
ベストプラクティス：
- 各ルールは500行以内で明確な目的を持つ
- 具体例とコード例を必ず提供
- 1スプリント内で1個のルール改善を推奨（任意）
この運用により、個人の実験的な改善がチーム全体の生産性向上に直結する仕組みを構築できました。
5月：MCP活用本格化
Model Context Protocol (MCP)の活用を本格化させました。
同僚の宮田さんがJira MCPからGitHub MCPまで実践＆布教することで、チーム全体の生産性が大きく向上しました。特にJiraチケットからPR作成までの連携により、従来の手動プロセスが大幅に効率化され、体感レベルでの明確な改善を実現。
僕はPlaywright MCPによるE2Eテスト自動生成、Browser tool MCPを活用したフロントエンド開発、Context7による最新ライブラリドキュメントの参照など、テスト・開発・調査の各領域でMCPを活用。
他の業務委託メンバーも積極的に参加し、例えば荒木田さんはFigma MCPを活用してデザイン・開発連携の効率化を実現するなど、各メンバーが自分の興味関心の領域でMCPを探求し、チーム全体にフィードバックするエコシステムが形成されました。
MCPセキュリティ運用ルール：
この時期に重要だったのは、セキュリティを考慮したMCP利用ルールの整備です：
- Docker優先原則：可能な限りDockerコンテナ内でMCPを実行
- 公式MCP優先：公式提供のMCPを最優先で採用
- TL検証制度：公式MCPが存在しない場合は、TL（テックリード）検証済みのもののみチーム利用を許可
- ホワイトリスト管理：承認されたMCPのみを記載したホワイトリストの維持・更新
MCP活用例：
- タスク管理 → コード管理システム自動連携
- PR作成時の関連ドキュメント自動参照
- 開発完了時のナレッジベース自動更新
Playwright E2E自動生成：技術的チャレンジ
PlaywrightとBrowser tools MCPを組み合わせたE2E自動生成基盤も構築しました。これは従来のテスト開発における根本的な課題解決を目指した取り組みです。
従来のE2Eテストの課題：
- 専門的スキルの壁：テストコード作成に専門知識が必要で、非開発者の参加が困難
- テスト作成の工数：人手でのテストケース設計・実装に多大な時間とリソースが必要
- メンテナンスの負担：UI更新時の手動修正作業
- 認知バイアス：人間が考える範囲に限定されたテストシナリオ
AI活用による革新的アプローチ：
# 自然言語によるテスト指示
Playwright MCPを使って以下のE2Eテストを実行してください：
1. [管理システム]ログイン http://localhost:3060/[system]/login
2. アカウントID：[admin_id], PW：[password]
3. 新規起票ページに遷移
4. 医療機関選択で「[テスト医療機関]」を選択
5. [患者名]の患者同期を実行
6. 同期完了まで待機し、新規起票ボタンが表示されることを確認
AIが生成する堅牢なテストコード：
// アクセシビリティベースの要素選択戦略
await page.goto('http://localhost:3000/[system]/login');
await page.getByRole('button', { name: 'ID・パスワードでログイン' }).click();
await page.getByRole('textbox', { name: 'アカウントID' }).fill('[admin_id]');
await page.getByRole('textbox', { name: 'パスワード' }).fill('[password]');
await page.getByRole('button', { name: 'ログイン' }).click();
// IDやClass名に依存しない堅牢なセレクタ
await expect(page.getByRole('heading', { name: '[ダッシュボード画面]' })).toBeVisible();
...
重要な技術的判断：
- getByRole()最優先：IDやClass名の変更に強い、アクセシビリティツリーベースの選択
- 自然言語→コード変換：非技術者でもテスト作成に参加可能
- コンテキスト理解：AIがWebページの構造と意味を理解し、最適な要素選択を判断
この取り組みにより、開発者と非開発者の協働によるテスト文化の実現と、UI変更に適応する自動テスト基盤の構築を達成しました。
外部システム連携テストの自動化：
特に医療システムでは多数の外部システム連携が存在するため、Playwright MCPの真価が発揮される領域です：
- リグレッションテスト自動化：外部システムのUI変更に対する影響確認
- QA自動化：手動では時間のかかる外部連携フローの品質保証
- テストデータ作成自動化：外部システムでのデータ準備作業の効率化
- クロスシステム統合テスト：複数の外部システムを跨いだエンドツーエンドテスト
# 外部システム連携テストの例
Playwright MCPで以下の外部連携テストを実行：
1. [外部システムA]にログインしてテストデータを作成
2. [連携API]経由でデータ同期を実行
3. [自社システム]で同期結果を確認
4. [外部システムB]での処理状況を検証
従来は人手で数時間かかっていた外部システム間のデータ整合性確認が、自動化により数分で完了するようになりました。
Phase 2までの成果と次への展望
ここまでで実現できたこと
- 個人実験から組織文化へ：一人の取り組みがチーム全体の標準的なワークフローに変化
- 全職種でのAI協働：エンジニアだけでなく、PM/QA/デザイナーまで含めたAI活用文化の定着
- 知識循環の仕組み化：タスク完了時のナレッジベース更新が「別作業」から「作業の一部」に変化
- 技術基盤の確立：Cursor + MCP + ナレッジベースによる実用的なAI協働プラットフォーム構築
重要な学び
- 推進者の継続投入が必要：自然発生では限界があり、専任または準専任の推進者が不可欠
- 受け手から発信者への転換：チーム全体が知識の生産者になることが成功の鍵
- セキュリティと革新の両立：早期のルール整備により安全な拡張基盤を構築
後編への繋がり
Phase 2まででチーム全員AIフレンドリーな基盤は整いましたが、真の効果測定はPhase 3以降で明らかになります。
後編で扱う内容：
- Phase 3：AI協働前提のオンボーディング実証
- 具体的効果測定：新メンバーによる客観的な体験記と効果分析
- 実践的プロンプトテンプレート集：実際に使用している効果的なプロンプトテンプレート集
- 運用上の課題と解決策：継続的な改善サイクルの確立
- チーム内KPT：運用後の生の声
- 今後の展開：定量計測による継続的改善
---Update--
後編記事も公開しました！
興味のある方ぜひご覧ください！
関連リンク：
この記事が参考になった方は、ぜひXでシェアしていただけると嬉しいです！
フィードバックもお待ちしています。
🚀 一緒に働きませんか？
AI×ナレッジベースで組織力を向上させる取り組みに興味を持っていただいた方、開発メンバーを募集しているので、是非チェックしてみてください！
全社の採用ポジションはこちらからご確認いただけます。
AI協働文化を一緒に発展させていけるメンバーをお待ちしています！
Discussion