AI導入しても効果薄い？チーム全員AIフレンドリー！な環境の作り方、教えます（後編）

📖 3分で読める要約

🎯 後編で実現したこと

• AI協働前提オンボーディング：新メンバーの学習効率3倍向上を実証
• 客観的効果測定：第三者視点での「破格のキャッチアップ速度」証明
• 継続的改善サイクル：チーム内KPTによる運用課題の可視化と解決

🗓️ 本記事（後編）で扱う範囲

1. Phase 3（5-6月）：AI協働前提オンボーディング、効果測定・検証
2. 実践的コンテンツ：チームKPT、効果的プロンプト例、運用課題と解決策
3. 今後の展開：定量計測による継続的改善戦略

後編とは？

「AIツールを導入したけど、結局は個人の効率化止まり」

「他社も同じツール使ってるのに、なぜか効果に差が出る」

「AIにタスクを任せたいけど、結局人間が確認・修正で手間が増える」

そんな悩みを抱えている方も多いのではないでしょうか？

本記事では、個人の実験から始まって3ヶ月でチーム標準になった、AI×ナレッジベース活用の実践プロセスの詳細をお伝えする後編になります。

前編をまだお読みでない方は

https://zenn.dev/fastdoctor/articles/de25424a77cf77

【学生向け】医療 x 生成AIハッカソンのエントリー募集受付中です！（6/25まで）

https://note.com/fastdoctor/n/n59b1e8e8a61e

🗺️ 全体ロードマップ（再掲）

Phase 3: チーム標準化の実証（5-6月）

5月オンボーディング：AI協働前提の受け入れ

5月に新しいエンジニアをAI協働前提でオンボーディングしました。従来の方法との違いは歴然でした：

Before（AI導入前）：

• View表記調整の単純タスクで3日間
• 先輩エンジニアへの質問が中心
• 「分からないことが分からない」状態の長期化

After（AI+ナレッジベース活用）：

• 複数ModelとViewが関わる複雑タスクで2日間
• ナレッジベースとAIを活用した自己解決
• 「調べ方が分かる」状態への早期到達

6月成果：新メンバーによるリアルな体験記

6月に入った業務委託メンバーが、入社1週間で感じたAI+ナレッジベース活用の効果を技術ブログ記事として発信してくれました。

記事の引用（抜粋）：

「今の実情、入って1週間の仕事はコードリーディング/実装や調査/AIに指示出しが3/2/5（今までなら5/3/1+1）くらいの割合」

「コード調査や実装、レビュー依頼にかける時間は正直感覚値として今までの三分の一くらい」

「破格のキャッチアップ速度だと勝手に思っています」

https://zenn.dev/fastdoctor/articles/a9da421058266b

チーム内KPT：2週間運用後の生の声

運用開始から2週間後に実施したKPTから、リアルな声を抜粋：

Keep（継続すべきこと）

生産性向上:

• PRのレスポンス早くなった：コンテキストの理解が早く、的確なフィードバックが可能に
• コードレビューのベースラインをCursorに任せられる：人間は本質的な設計レビューに集中
• コード理解のスピードが上がった：新規参画時の学習曲線が大幅に改善
• エラー解決策の提示が的確：過去事例の蓄積により、類似問題への対応が迅速化

業務効率化:

• PR文章作成が効率化：変更内容から自動的に適切な説明文を生成
• KPT定期的にやる：振り返りの習慣が、AI活用方法の改善につながっている

Problem（課題）

技術的課題:

• Cursorが重い：大規模プロジェクトでのメモリ消費とレスポンス速度
• askとagentの切り替えが面倒：作業文脈に応じた最適なモード選択の複雑さ
• フロントのレスポンシブ対応が弱い：UI関連のコード生成における制限

学習・適応課題:

• 慣れが必要で疲労が高い：新しいワークフローへの適応期間中の認知負荷
• Notionをナレッジベースで使う場合、block単位取得が非効率：既存ツールとの連携における技術的制約（Notion社にて解決策リリース予定）

Try（改善策）

技術的改善:

• 課金モデル利用：Pro版への移行によるパフォーマンス向上
• obsidian×cursorを試す：より軽量なナレッジベース管理ツールとの連携実験
• 自身のAPI Keyで速度比較：個人のAPI利用による応答速度の改善

活用範囲拡大:

• Figma MCPなど利用：デザイン・開発連携の更なる効率化
• paperless-ngx, docusaurusを試す：ナレッジベース管理ツールの多様化実験

重要な気づき：

技術的な課題よりも**「慣れと疲労」**という人的要因が大きな障壁となることが明らかになりました。これは継続的な改善サイクルにより克服可能であることも確認できました。

実践的プロンプトテンプレート集

3ヶ月間の試行錯誤で辿り着いた、実践的なプロンプト活用法を段階的に公開します。

🔑 成功の秘訣：Planning（企画）とExecution（実装）を必ず分けること

一度に全てを指示するより、段階的にアプローチすることで品質とスピードが大幅に向上します。

🎯 STEP 1: ナレッジベースがない場合の実践的プロンプト

対象読者： AI初心者、今日から始めたい方

所要時間： 10分で習得、即実践可能

効果： 従来の作業時間を50%短縮

効果的プロンプトの4層構造

どんな環境でも使える、高品質な結果を得るための基本フレームワーク：

📋 実践例：患者検索機能の改善タスク

💡 学習ポイント： この例で4レイヤー構造の具体的な使い方を体感してください

Phase 1: 企画・分析（Planning）

### Goal（明確な目的）
患者一覧画面の検索機能を改善し、医師が効率的に患者情報を見つけられるようにする。
具体的には、複数条件での絞り込み検索と検索結果のリアルタイム表示を実装する。
まず実行計画を作成しましょう

### Output Format（期待する形式）
以下の形式で成果物を提供してください：

1. 実装方針書（.md形式）
   - 技術的アプローチ
   - データベース変更の有無
   - セキュリティ考慮事項
   - 想定される課題と対策
   - 実装内容整理
   - 動作確認手順書

### Context（実行文脈）
- プロジェクト：Fast DOCTOR（医療システム）
- 技術スタック：Rails　version + React version
- データベース：PostgreSQL version
- 対象画面：患者一覧画面（`app/views/xxx/patients/index`）
- 関連モデル：`Patient`, `Reception`, `MedicalExamination`

#### 💻 技術的詳細
1. **既存コード規約準拠**：
   - Controllerは既存の`XXX::PatientsController`を拡張
   - サービスクラスは`app/services/`配下に配置
   - GraphQL使用時は`app/graphql/`の構造に従う

2. **検索条件**：
   - 患者名（部分一致・ひらがな/カタカナ対応）
   - 患者ID（完全一致）
   - 生年月日（範囲指定）
   - 受診日（範囲指定）
   - 診療状況（ステータス）

3. **UI/UX要件**：
   - リアルタイム検索（入力後500ms で自動検索）
   - 検索結果のページネーション（20件/ページ）
   - 検索条件のクリア機能
   - 検索履歴の保存（セッション内）

#### 🔧 実装パターン
1. **バックエンド構成**：
   - Controller: 検索API エンドポイント
   - Service: 検索ロジック（`PatientSearchService`）
   - Query Object: 複雑な検索条件構築

2. **フロントエンド構成**：
   - 検索フォームコンポーネント
   - 結果表示コンポーネント
   - デバウンス機能付き検索フック

3. **テスト要件**：
   - Controllerテスト：検索API の各パターン
   - Serviceテスト：検索ロジックの境界値
   - Featureテスト：E2E検索シナリオ

### Instructions（制約・補足）
以下のルールと制約を必ず守って実装してください：

#### 🏥 医療システム固有の制約
1. **個人情報保護**：患者情報の検索・表示時は必ずアクセス権限チェックを実装
2. **データマスキング**：検索結果には患者名の一部マスキングを適用
3. **監査ログ**：検索実行時のログを記録
4. **パフォーマンス**：大量データ検索時も3秒以内の応答時間を維持

#### ⚠️ その他注意事項
- 患者情報は機密性が高いため、SQL インジェクション対策を徹底
- 検索条件によってはN+1問題が発生する可能性があるため、includes/joinsを適切に使用
- 大量データでの検索時はバックグラウンドジョブ化も検討

Phase 2: 実装（Execution）

💡 Planning効果の実感ポイント： 詳細な企画ができていると、実装指示がこれだけシンプルになります

@Planning.mdに基づいてstep by stepで実行しましょう

📊 効果測定結果（個人）：

• Before
  • 従来の一括指示：5-8時間（品質にばらつきあり）
• After
  • Planning時間：30分 → 実装・テスト時間：2時間 = 合計2.5時間
• 効率向上：50-70%、品質の安定化も実現

🏗️ STEP 2: ナレッジベース構築の実践方法

対象読者： STEP1で効果を実感、本格導入を検討している方

所要時間： 2-4週間で基盤構築

効果： チーム全体の効率を継続的に向上、知識資産の蓄積

🎯 投資判断の目安： STEP1で個人当たり週5時間以上の効率化を実感した場合、ナレッジベース構築をおすすめします

Fast DOCTORで実証済み：効率的な二段階ナレッジベース構造

🔧 1層目：.cursor/rules（基本ルール・最小限の情報）

• 目的： AIの迅速な判断と方向性決定
• 内容： 行動指針、制約条件、参照関係の定義
• 特徴： 軽量、高速読み込み、チーム共通基盤

📚 2層目：doc/（詳細情報・関連付けられた知識）

• 目的： 具体的な実装方法と背景知識の提供
• 内容： 技術仕様、実装パターン、トラブルシューティング
• 特徴： 自動連携、継続的更新、実践的知見蓄積

実際の構築例：02-architecture.mdc

.cursor/rules/02-architecture.mdc（1層目：基本ルール）

---
description: システムアーキテクチャの基本方針とAI協働ガイドライン
globs: ["**/*.md", "app/**/*", "config/**/*"]
alwaysApply: false
---

## 概要
Fast DOCTORシステム全体のアーキテクチャと、AI協働時の注意点

## システム構成図
[mermaid図で全体構成を可視化]

## コンポーネント
### フロントエンド（5つのサブプロジェクト）
### バックエンド（Rails API、GraphQL）
### データストア（PostgreSQL、Redis、S3）
### 外部サービス連携（Mobakar、Owel等）

## AIプログラミングにおける注意点
1. **モノレポ構造**：各サブプロジェクトの境界を尊重
2. **API連携**：フロントエンドは必ずAPI経由でアクセス
3. **バックグラウンド処理**：重い処理はSidekiqジョブとして実装
4. **外部サービス連携**：専用ゲートウェイクラス経由

## 関連ドキュメント
- [プロジェクト概要](01-project-overview.md)
- [バックエンド開発ガイドライン](04-backend-guidelines.md)
- [フロントエンド開発ガイドライン](05-frontend-guidelines.md)
- [外部連携詳細](doc/architecture/overview.md)

doc/architecture/integrations/external_system_sync.md（2層目：詳細情報）

# 外部システムジョブの処理フローと連携

## 概要
外部システムとの連携を行うジョブの処理フローと関係を整理

## ジョブの分類
### 1. 同期系ジョブ（15個の個別ジョブ）
### 2. 一括同期トリガージョブ（3個）
### 3. 書き戻し系ジョブ（3個）
### 4. その他のジョブ（3個）

## ジョブ間の依存・実行関係
[mermaid図で複雑な依存関係を可視化]

## 各ジョブの詳細
#### ExternalObjectListSyncJob
- **目的**: ObjectIDリストを同期する
- **操作するモデル**: ExternalSyncJobLog, Object, Contract
- **サービスクラス**: External::ObjectListSync
- **主要な処理フロー**: 4ステップの詳細手順
- **条件分岐**: 5つの if 条件とその処理

📅 ナレッジベース構築の段階的アプローチ

🚀 Week 1-2: 最小限のRules作成

• ✅ 01-project-overview.mdc：プロジェクト全体の概要
• ✅ 02-coding-standards.mdc：基本的なコーディング規約
• ✅ 03-project-structure.mdc：ディレクトリ構造と役割
• 目標： 基本的なAI協働を開始、効果測定開始

📈 Week 3-4: 詳細ドキュメント追加

• ✅ doc/配下に既存の技術仕様書を整理
• ✅ rulesからの参照関係を設定
• ✅ 実際のタスクで使いながら改善
• 目標： チームメンバーが自発的に活用開始

🔄 Week 5-8: 継続的改善

• ✅ チームでのKPT実施（2週間間隔）
• ✅ 使用頻度の高い情報の優先的な整備
• ✅ 自動化による更新負荷軽減
• 目標： 組織文化として定着、ROI実証

🚀 STEP 3: ナレッジベース完成後のタスク依頼 - ここまで楽になる！

対象読者： ナレッジベース構築完了、チーム標準化を目指す方

所要時間： プロンプト作成1分、高品質な結果を瞬時に獲得

効果： STEP1比でさらに70%効率化、チーム全体の知識レベル底上げ

🎯 感動ポイント： 複雑なタスクがわずか数行の指示で高品質に完成する瞬間を体験してください

🎯 Pattern 1: 企画・分析（Planning）

# Goal
[JiraチケットURL]要件を分析し、Fast DOCTORアーキテクチャに適した実装方針を設計する

# Output Format
.md

# Context
use context7
use Atlassian

# Instructions
1. 既存のReceptionモデルとの整合性を保つ

⚡ Pattern 2: 実装（Execution）

# Goal
`@Planningで生成された実行プラン` 設計方針に基づき、実際のコードを生成・実装する

🔍 Pattern 3: レビュー・改善（Review）

# Goal
コードレビューと改善コメント

# Context
[対象PRのリンク]
use context7
use github
use Atlassian
コードレビューして
1. 要件を満たしているかどうか
2. Bugやセキュリティ欠損があるかどうか
3. コード改善できるかどうか
4. 他の考慮漏れがあるかどうか

🎯 驚異的効率化を実現する3つの技術的秘密

1. 🧠 .cursor/rulesによる文脈の自動適用

• 効果： プロジェクト固有の制約条件が指示なしで自動考慮
• 実例： 医療システムのセキュリティ要件を毎回説明不要(Rulesとナレッジが自動担保)

2. 📚 doc/からの関連情報自動参照

• 効果： 類似実装パターンの自動検索・適用
• 実例： 過去の成功事例を自動で踏襲、車輪の再発明を防止

3. 🔗 MCPによる外部システム連携

• 効果： use context7、use Atlassian等で最新情報を自動統合
• 実例： JiraチケットやAPI仕様書の自動参照

💰 ROI計算： 初期投資（ナレッジベース構築2-4週間）→継続的リターン（チーム全体の生産性向上）= 投資回収期間：約1ヶ月

成功・失敗パターンの実践知見

✅ 成功パターン

1. 継続的教育プログラム：全職種対応による文化定着
2. 受け手から発信者への転換：全メンバーがナレッジベース貢献者になる仕組み
3. QAチームの自発的推進：「これ他でも使えそう」という視点での自発的更新
4. AI協働前提オンボーディング：従来の1/3期間での複雑タスク対応

❌ 失敗パターン

1. 自然発生への過度な期待：推進担当者なしでの展開は困難
2. AI依存の兆候見過ごし：AIのアウトプットを思考停止で受け入れてしまう
3. 技術進化への対応遅れ：日々進化するAI技術のアップデートに追いついていけない、試さない
4. 個人差への対応不足：画一的な効果測定基準による柔軟性不足

今後の展開と継続的改善

Phase 4：定量計測による効果の見える化（6月から）

現在は体感レベルでの効果実感が中心ですが、今後は以下の定量指標による継続的な改善サイクルを確立：

計測指標：

• サイクルタイム計測：リードタイム追跡、AI活用有無による比較分析
• 生産性の多角的評価：機能リリース数、技術的負債解消への投資時間
• 見積もり精度の改善：計画vs実績の差分分析
• 知識資産の成長指標：ナレッジベース利用頻度、知識循環率、再利用効率
• チーム協働指標：自己解決率、質問品質スコア、相互教育効果
  

継続的改善サイクル

運用ルール：

1. AI自動化によるナレッジベース更新の効率化：コード変更検知→関連ドキュメント自動更新
2. experimental/ディレクトリでの個人実験→チーム展開フロー：安全な実験環境→効果検証→チーム標準昇格
3. MCP活用による外部システム連携：Jira↔GitHub自動連携、Figma↔実装同期

最後に：なぜ多くのAI導入が効果実感難いのか？ 3つの成功要因

🧠 成功要因1：ナレッジベースが組織の知的資産の中核になる

なぜナレッジベースが必要なのか？

AI導入で「効果薄い」と感じる最大の理由は、組織固有の知識がAIに届いていないことです。

• ❌ 失敗パターン：汎用的なプロンプトでの質問 → 汎用的な回答 → 「使えない」
• ✅ 成功パターン：組織のナレッジベース + AI → あなたの組織に特化した高品質な提案

ナレッジベースの真の価値は「情報の蓄積」ではなく「知識の循環」

我々では、**「一度解決した問題は二度と同じ時間をかけない」**という文化が根付きました。これがチーム全体の生産性を複利的に向上させる秘密です。

🔬 成功要因2：小さな実験とPDCAサイクルが未来を変える

なぜ実験が重要なのか？

AI技術は日単位以上で進化しています。「完璧な計画」を待っていては、永遠に始められません。

重要な気づき：「完璧を目指すより、改善を続ける」

• 最初のナレッジベースは「とりあえず動く」レベルで十分
• 使いながら改善することで、本当に必要な情報が見えてくる
• チームの習慣になれば、自然と質が向上する

🤝 成功要因3：チーム一体となった取り組みが個人の限界を超える

なぜ一人では限界があるのか？

AI活用は個人スキルではなく、組織文化です。一人だけが効率化されても、チーム全体の成果は変わりません。

チーム協働で得られた驚きの効果：

チーム全員がAIフレンドリーになった瞬間の変化：

「今まで『分からないことを聞く』だったのが、『調べて試してから相談する』に変わった。質問の質が圧倒的に向上し、全員の学習スピードが上がった」（チームメンバーの声）

🎯 チーム標準化の3つのメリット

1. 知識の民主化：ベテランの知見が新人にも即座に伝承
2. 品質の標準化：AIによる一定品質の担保 + 人間による本質的レビュー
3. 学習の加速化：個人の学習サイクルがチーム全体の資産に変換

🚀 あなたのチームも明日から変われる：行動指針

我々の3ヶ月の実践から、確信を持って言えること：

💡 変革の第一歩は「今日、一人で始める」こと

• 完璧なナレッジベースを目指さず、明日使える最小限のルールから
• チームの説得は、効果を体感してもらってから
• 「実験です」と言えば、失敗してもOKな環境を作れる

🔄 継続の秘訣は「チーム全体の習慣化」

• 個人の効率化から、チームの知識循環システムへ
• 受け手から発信者へ：全員がナレッジベース貢献者になる仕組み
• 定期的なKPTで、常に改善サイクルを回し続ける

🎯 目指すゴールは「AIフレンドリーなチーム文化」

• AIは道具、真の価値はナレッジの循環による価値創作
• 個人のスキルアップ ✕ チームの知識資産 = 組織力の複利的成長
• 一度作ったナレッジベースは、チームの未来永続的な資産になる

私たちの3ヶ月間の実践が、その確信を与えてくれました。

関連リンク：

• AI導入しても効果薄い？チーム全員AIフレンドリー！な環境の作り方、教えます(前編)
• 新メンバーによるオンボーディング体験記（Zenn）
• Coding Agent at Loft #2 発表資料

🚀 一緒に働きませんか？

AI×ナレッジベースで組織力を向上させる取り組みに興味を持っていただいた方、開発メンバーを募集しているので、是非チェックしてみてください！

🔗 エンジニア採用情報

全社の採用ポジションはこちらからご確認いただけます。