
1. はじめに:CodingAgent時代のT型人材への挑戦
私は長年Androidエンジニアとして活動してきました。しかし、Android専業への危機感を抱いていました。CodingAgentが台頭する時代、単一技術の専門家では限界があると感じていたのです。
動機:Android専業からの脱却
- AIによる業務効率化で生まれた空き時間を活用
- Android開発経験を一本の柱とし、専門外開発を全うできるかの実証実験
- 社内で頻発する労務相談を効率化する実践的課題に着目
この挑戦は、CodingAgent時代のT型人材への転換を目指す実験でした。
開発はAIで業務が効率化した空き時間のみで実施しました。21日間の期間中、実際の作業日数は11日間という断続的なスケジュールで進めました。
開発は2段階で進行しました
- Phase 1(7/15-17): プライベートリポジトリでのプロトタイプ開発(3日間)
- Phase 2(7/18-8/4): 企業リポジトリでの本格開発・MVP完成(8日間)
- 総期間: 21日間(7/15-8/4)、実作業: 11日間
構築したRAG型労務AIエージェントの概要
社内Backlog Wikiの労務情報を自動同期してDifyナレッジベースを構築し、SlackからのDMで労務相談に応答するRAG(Retrieval-Augmented Generation)システムを開発しました。
システム構成
【RAG型労務AIエージェントのシステム構成】

【処理フロー】
1. Backlog Wiki(労務情報)
↓ [定期同期: node-cron]
2. Dify Dataset(ナレッジベース構築)
↓ [RAG検索・生成]
3. Slack Bot(DM応答)
↓ [自然言語処理]
4. 社員への労務相談回答
技術スタックと選定理由
| 技術 | 用途 | 選定理由 |
|---|---|---|
| TypeScript | 開発言語 | Android開発での型安全性経験を活用 |
| Google Cloud Run | 実行基盤 | サーバーレスでの運用コスト最適化 |
| Dify | RAGプラットフォーム | Backlog API連携とナレッジベース管理の充実 |
| Slack Bolt | Bot Framework | Socket Mode対応とイベント処理の安定性 |
| Next.js | Web管理画面 | モダンなUI開発とSSR対応 |
本記事の評価は筆者の経験と観測に基づくものです。技術選択は、プロジェクトや企業により大きく異なります。
2. Android経験を活かした転用戦略
バックエンド開発は未経験でしたが、Android開発で培った知識の転用により、効率よく新技術を習得できました。
メタ認知による技術探索プロセス
メタ認知を活用した学習プロセスとは、「自分が何を知っていて、何を知らないか」を客観視し、既存知識を新領域に適用する思考法です。
具体例:テストフレームワークの選定
1. Androidでの経験を分析 「JUnitで何をしているか?」→「関数の入出力を検証している」 2. 本質を抽出 「関数の振る舞いをテストする仕組みが必要」 3. TypeScriptで同じ役割を探索 「TypeScript unit test framework」で検索 4. Jestを発見し、概念の類似性を確認 @Test → test()、assertEquals() → expect().toBe()
このプロセスにより、「何を探せばいいか」が明確になり、学習効率が大幅に向上しました。
知識転用マップの実践
テスト・品質管理:JUnit→Jest、Android Lint→TypeScript型チェック
パフォーマンス分析:Android Profiler→Node.js分析、メモリリーク検出→サーバーリソース管理
アーキテクチャ設計:MVVMパターン→レイヤードアーキテクチャ、DIパターン→モジュール化
Issue駆動開発の実践
Issue駆動開発とは、課題を明確に定義してから実装に着手する手法です。
実例:Issue #17 - DM応答が動作しない
1. 問題定義 「労務相談BotがDMに応答しない」 2. 成功条件の明確化 ✓ RoumuBot宛のDMのみに応答する ✓ 他ユーザー間のDMには反応しない ✓ グループメッセージは無視する 3. テスト可能な形で実装 - ユニットテスト作成 - API仕様確認 - 実装・検証
この手法により、未経験分野でも着実に前進できました。
3. 11日間の開発プロセスと3つの壁
第1の壁:本番環境とCodingAgent活用の落とし穴
課題: 環境変数未設定と深刻なプライバシー問題
学び: CodingAgentに頼りすぎた開発の危険性
ローカル環境では順調でしたが、Cloud Runデプロイ後に問題が発生しました。
環境変数管理の違い(Android vs バックエンド)
- Android: BuildConfigで管理、ビルド時に固定
- バックエンド: Secret Managerから実行時に取得、環境ごとに異なる値を動的に管理
さらに深刻な問題が発覚しました。他のユーザー同士のDM(ダイレクトメッセージ)が、労務相談Bot宛てのメッセージと誤認識され、外部のDify APIに送信されてしまっていたのです。
問題の詳細
- Slackには複数のBotが存在(労務相談Bot、通知専用Botなど)
- 通知専用Bot(SlackシステムBot)経由で届く他ユーザー間のDM通知
- これらの通知が「労務相談」として誤処理され、社外APIに送信
CodingAgent時代の教訓:「指示の品質」が成果を決める
私はClaude Codeを活用して開発を進めていましたが、DM判定ロジックを「DMなら参加者は2人だろう」という推測で実装させてしまいました。
// ❌ CodingAgentが推測で実装したコード const isValidDM = members.length === 2 && members.includes(userId) && members.includes(botUserId); // ✅ Slack API仕様書を確認後の正しい実装 const channelInfo = await slack.conversations.info({ channel }); const isValidDM = channelInfo.channel.is_im && channelInfo.channel.user === botUserId;
推測禁止・API仕様準拠開発の重要性
「推測禁止」とは、仕様書なしで「たぶんこうだろう」と実装しない原則です。特に専門外領域でCodingAgentを使う際は、以下の指示が必須でした
「実装前に必ずSlack API公式ドキュメントを確認し、 推測ではなく仕様に基づいて実装してください」
この経験から、CodingAgentへの指示には「推測禁止・API仕様準拠」を明示的に含めるという開発原則を確立しました。
第2の壁:RAGシステムのパフォーマンス最適化
課題: 大幅な応答遅延
学び: 順を追った最適化とAndroid経験の活用
社内メンバーのテストで「応答が遅すぎて使い物にならない」というフィードバックを受けました。調査すると、RAGシステム(Backlog Wiki→Dify→LLM→Slack Bot)で複数API呼び出しによる大幅な遅延が発生していました。
RAGシステムの処理フロー
- ユーザー質問(Slack DM)
- Dify APIでナレッジベース検索
- 関連文書の取得・ランキング
- LLMによる回答生成
- Slack Bot応答
Android開発でのパフォーマンス分析経験を活かし、ボトルネックを一つずつ特定しました。
3段階最適化アプローチ
- モニタリング重複削除:ログ出力の重複を削除し、真の問題を特定可能に
- タイムアウト延長:Cloud Run環境のネットワーク遅延を考慮して設定延長
- Fallback-First実装:DifyのRAG検索で安定したAPIを最優先に
さらにレガシーサービス2重実行問題も発覚しました。同じSlack App Tokenを使用した複数サービスが並行稼働し、Socket Modeで重複処理が発生していました。この課題でも、Androidでのマルチプロセス管理経験を応用して問題を分析・解決しました。
ユーザビリティ向上一時応答機能の実装
応答時間改善と並行して、一時応答機能を実装しました。RAGシステムでは検索・生成に時間がかかるため、「確認中です。少々お待ちください...」を即座に返答し、その後詳細回答を送信する仕組みです。
これにより、ユーザーは「システムが動作している」ことを確認でき、ユーザーが感じる応答性が向上しました。
実際のSlack DM画面。「確認中です。少々お待ちください...」の一時応答後、夏季休暇に関する詳細な労務情報を構造化して回答している様子
結果、応答時間を大幅に短縮でき、実用可能なシステムに改善できました。
第3の壁:企業級品質の実現
課題: 予期しない動作と可視性不足
学び: ログ強化とセキュリティ完全封鎖の重要性
最終段階では、企業利用に耐えうる品質確保に取り組みました。時折発生する予期しない動作の原因を特定するため、全体を網羅したログシステムを実装しました。
console.log(`[DM] ===== STARTING DIRECT MESSAGE HANDLER =====`); console.log(`[DM] Processing user message from ${message.user}`); console.log(`[DM] ===== DIRECT MESSAGE HANDLER COMPLETED =====`);
このログ強化により、問題発生時の原因特定が効率化されました。バックエンド開発では「何が起きているかの可視性」が重要であることを実感しました。
さらに全プライバシー経路の完全封鎖を実装し、企業利用対応のセキュリティレベルを達成しました。Socket Mode接続安定化、TypeScript完全対応、メモリリーク対策により、実際の運用では高い可用性を安定して達成できました。
4. 技術的成果とシステムの価値
MVP完成と実戦投入成功
21日間(実作業11日間)の断続的作業でのClaude Codeとの協働により、以下を達成しました。
技術的成果
- RAGシステム完成:Backlog Wiki→Dify自動同期による労務知識ベース構築
- 応答時間:大幅な改善により実用可能な速度を実現
- 可用性:高い安定稼働を実現
- セキュリティ:企業利用対応のプライバシー保護
- Issue解決数:多数の課題を順次解決
RAGシステムの価値
社内に散在していた労務情報(Backlog Wiki)を自動的にDifyナレッジベースに同期し、Slackから自然言語で相談できる仕組みを実現しました。これにより、従来は人手で対応していた労務相談を効率化できました。
5. T型人材としての学習
専門外開発の核心的学習
この挑戦を通じて、CodingAgent時代のT型人材として必要なスキルを体得しました。最も重要な学習は「CodingAgentへの適切な指示出し」の重要性でした。
Android開発経験が活かされた領域
- JUnit→Jestの読み替え:テスト手法の知識を直接応用
- TDD(テスト駆動開発):単体テストオールグリーンをゴールとする開発手法
- Issue駆動開発:課題を明確に定義してから解決に取り組む手法
- メタ認知活用:自分の学習プロセスを客観視して効率化
効果を上げた転換アプローチ
- 既存知識の読み替え:JUnit→Jest、パフォーマンス分析手法の応用
- メタ認知の活用:学習プロセス自体を最適化
- 順次課題解決:Issue駆動による明確な目標設定
- テスト駆動による品質確保:Androidと同様の品質基準を維持
6. 実践から得た知見と応用可能性
この開発で得た知見は、以下の領域で活用可能です
RAGシステム構築パターン
- 既存ドキュメント資産のAI活用
- ナレッジベース自動更新の仕組み
- 検索精度とレスポンス速度の両立
エンタープライズAI開発の要点
- プライバシー・セキュリティ設計
- 順を追った品質向上プロセス
- 実用可能なMVP開発手法
これらは様々な場面で使える技術パターンとして、今後のAIプロジェクトに応用できる貴重な資産となりました。
7. 後進への実践的アドバイス
Android→バックエンド転換を成功させるポイント
- CodingAgentへの明確な指示 - 「API仕様準拠」を必ず含める
- 既存スキルの読み替え - JUnit→Jest、パフォーマンス分析手法の応用
- 順次課題解決 - Issue駆動による明確な目標設定
- 品質基準の維持 - Android開発と同等の品質意識を持つ
次の一歩:今すぐ始められる3つのアクション
- 小さなバックエンドプロジェクトを始める:まずはシンプルなAPIサーバーやBot開発から
- Issue駆動開発を実践:既存プロジェクトでも、課題を明確に定義してから着手する習慣を
- CodingAgentツールを活用:Claude CodeやGitHub Copilotを使い、効率的な開発手法を体得
8. まとめ
21日間(実作業11日間)という短期間でRAG型AIエージェントのMVPを完成させることができました。これは、Android開発で培った専門性を基盤とし、メタ認知による学習プロセス最適化とCodingAgentとの適切な協働により実現しました。
最も重要な学びは、専門外領域でCodingAgentを活用する際の「指示の品質」の重要性でした。「推測禁止・API仕様準拠」という原則を確立することで、手戻りを防ぎ、効率的な開発を実現できました。
CodingAgent時代において、エンジニアの価値は「コードを書くこと」から「適切な課題設定と品質確保」にシフトしていくでしょう。Android開発者の皆さんも、ぜひ自分の専門性を活かした新しい技術領域への挑戦を始めてみてください。T型人材としての成長は、必ずキャリアの大きな武器になります。