タイ・ラオス開発チームでAIコーディングエージェントを定着させる90日ロードマップ

「Claude Codeを試したら便利だった」で終わるか、「チーム全員が同じ品質で使えるようになった」まで進めるか。この差は個人の技量ではなく、リポジトリのルール・レビュー基準・CIの整備にかかっています。Claude Codeのような開発エージェントは、個人が使うだけなら数日で成果が出ます。しかし駐在員と現地エンジニアが混在するタイ・ラオスの開発チームで品質を揃えるには、CLAUDE.mdの整備からレビュー基準、言語の壁への対処、成果指標の置き方まで、個人利用とは別の設計が必要になります。本記事は、この一連の設計を90日単位の段階別ロードマップとして解説します。オフショア開発の管理者やテックリードが、明日から使える手順として読み進められる内容です。

個人がAIコーディングエージェントを使いこなすことと、チーム全体で品質標準を揃えることは、まったく別の課題です。タイ・ラオスの混成チームでは、駐在員と現地エンジニアの間で言語、レビュー文化、開発環境が異なり、この差が導入の壁として表面化しやすい状況が見られます。たとえば同じレビューコメントでも、日本語ニュアンスの行間を読む前提で書かれていると、現地エンジニアには意図が伝わらず、AIエージェントが生成したコードの採否判断にズレが生じることがあります。次のH3では、この違いと壁の具体像を整理します。

個人がClaude Codeを試す場合と、チームで導入する場合とでは前提がまったく異なります。個人利用では、エンジニアが自分の端末にClaude Codeを入れ、自分の作業スタイルに合わせて指示を出し、成果物も自分でレビューして終わります。ルールは頭の中にあれば十分で、誰かに共有する必要もありません。

一方チーム導入では、指示の書き方・出力の受け入れ基準・レビューの通し方を、メンバー全員が同じ理解で運用できる状態を作る必要があります。リポジトリに置く CLAUDE.md のようなルールファイルがチーム共通の資産として機能しているか、レビューでの確認項目やCIでの検証基準がメンバー間で揺れていないかが問われます。

この違いを見落としたままPoCを進めると、駐在員が使えば速いが現地チームに広げると品質がばらつく、という状態に陥りやすくなります。個人の熟練度に依存した運用は、メンバーの入れ替わりや拠点間の分業が発生した時点で崩れてしまいます。導入初期から、個人のスキルではなく仕組みとして再現できる形を目指すことが、90日ロードマップ全体の前提になります。

タイとラオスの開発チームに導入すると、言語・レビュー文化・環境差という3つの壁に共通してぶつかります。

もっとも影響が大きいのは言語の壁です。CLAUDE.mdやシステムプロンプトを英語だけで書くと、タイ語や日本語を母語とするメンバーが意図を誤読し、指示と異なる実装をAIが出力するケースが報告されています。実際、レビューコメントと指示文の言語がバラバラなチームでは、同じ修正依頼が3往復しても意図が伝わらないことがあります。指示文とレビューコメントをどの言語で統一するかは、導入初期の設計事項として決めておく必要があります。

次に大きいのがレビュー文化の壁です。上位者の指示に従う傾向が強い現場では、AIが出した実装を「上から降りてきた答え」として扱い、疑問を挟まずマージしてしまう場合があります。AIの提案は仮説であり検証対象だという前提を、レビュー基準に明文化しておくことが欠かせません。

環境差の壁は、前の2つに比べると対処自体は難しくありません。バンコクの本社チームとラオスの拠点でNode.jsのバージョンやローカルの権限設定が揃っていないと、同じ指示でも出力結果や実行結果が変わります。開発環境の差分を洗い出し、バージョンを固定するだけでも多くは解消します。

3つの壁は個別ではなく連動して定着を妨げるため、次章で扱う前提条件の整備でまとめて対処します。

導入初日から迷わずAIエージェントを使い始められるチームと、初日から指示の解釈違いでレビュー差し戻しが続くチームがあります。この差を生むのは事前準備の有無です。具体的には、CLAUDE.md やAGENTS.mdによる指示の明文化と、マージ条件を含むレビュー基準の2点を、導入前に整えておく必要があります。特にタイ・ラオスのように開発拠点と意思決定者が離れているチームでは、口頭やチャットでの補足に頼れないため、この2点を文書として固定しておくことが後々のすれ違いを防ぎます。

CLAUDE.mdに何を書き、何を書かないかで、その後の運用のしやすさが大きく変わります。

Claude Codeはリポジトリ直下のCLAUDE.mdを読み込み、コーディング規約やディレクトリ構成の意図を把握したうえで作業します。書く内容は、命名規則・使用禁止のライブラリ・テスト実行コマンド・タイ語やラオス語のコメントを許容するかどうかといった、口頭では伝わりにくい暗黙知に限定するのが実践的です。逆に、プロジェクトの背景説明や長い理念を書き込むと、コンテキストウィンドウを圧迫し、肝心の制約が読み飛ばされる原因になります。

タイ・ラオスの開発現場では、駐在員が英語で書いた指示と現地エンジニアの実装習慣がずれるケースが起きやすい傾向があります。この壁への対処として、CLAUDE.mdには「なぜそのルールが必要か」を一文添えると、単なる禁止事項の列挙より現地メンバーの納得感が高まります。たとえば「タイ語コメントは可、ただし関数名とログ出力は英語で統一する」のように、許容範囲と理由をセットで書くと、レビュー時の指摘も減ります。

AGENTS.mdは、Claude Code以外のエージェントも併用するチームで共通指示を切り出す用途に向いています。最小限のルールから始め、失敗が起きた箇所を追記していく運用で十分です。詳細な整備手順はClaude Code チーム導入ガイドでも扱っています。

外部API連携や決済ロジックに関わる変更は人間レビューを必須にし、軽微な修正は自動チェックのみで通す。この線引きをあらかじめ決めておくかどうかが、定着の分岐点になります。レビュー基準を曖昧にしたまま導入すると、「AIが書いたコードだから信頼度が高い」という思い込みが生まれ、確認が甘くなり、後工程での手戻りが増える傾向があります。

マージ条件はチェックリスト化しておくと現地チームでも判断がぶれません。単体テストが通っていること、命名規則がCLAUDE.mdの規約と一致していること、AIが生成した箇所には差分コメントを残すこと。これらをPull Requestのテンプレートに組み込んでおくと、レビュアーごとの基準の揺れを防げます。

タイ・ラオスの現場では、レビュアーが駐在員に偏ると承認待ちのボトルネックが生じやすいため、現地シニアエンジニアにもレビュー権限を分散させておくことが重要です。マージ条件を明文化しておけば、AIの提案を採用するか差し戻すかの基準が個人の経験に依存せず、チーム全体で再現可能になります。レビュー負荷を減らしながら品質のばらつきも抑えられるという、実務上の利点もあります。

最初の30日は対象範囲を絞り、失敗しても影響が小さいタスクから始めるのが定着の近道です。全社展開を急ぐと現場の反発を招きやすく、特にタイ・ラオスの開発チームでは「上から降ってきた新ツール」への警戒感が強い。まずは一部チームで小さく試し、うまくいった型を後の期間で広げる方が結果的に速い。次の項目では、この期間に選ぶべきタスクの基準と、ルール整備の進め方を具体的に示します。

最初の30日でどのタスクをClaude Code（クロードコード）に割り当てるべきか、判断に迷う現場は少なくありません。

選定基準は「仕様が明確で、正解が一意に近いか」です。CRUDのAPI実装、既存パターンに沿ったUIコンポーネント追加、単体テストの生成、README・APIドキュメントの整備などは仕様のブレが小さく、AIコーディングエージェントが得意とする領域です。逆に、業務ロジックの意思決定を含む実装や、要件が口頭でしか共有されていない機能追加は避けるべきです。仕様が曖昧なタスクをAIに任せると、レビューでの指摘が増え、現場の「使えない」という評価につながりかねません。

判断が分かれやすいのは既存コードのリファクタリングです。テストが整っている場合はAIに任せ、テストがない場合は人間が先にテストを書いてから任せる、という切り分けが有効です。テスト生成自体も、E2Eテストのような環境依存が強いものより、単体テストのように入出力が明確なものから始めたほうが、失敗した際の原因を小さく絞り込めます。

ドキュメント生成は副産物としての価値も大きく、レビュー負荷が低いため初期タスクに向いています。

口頭指示より文書化された失敗記録のほうが再現性を持つかどうか、これが最初の30日を左右します。

CLAUDE.mdに書くルールを完璧に作り込もうとしがちですが、実際には未完成のまま運用しながら失敗を追記していくほうが効きます。仕様の抜け漏れは事前の想像より、実際にAIコーディングエージェントに実装させたときの出力で初めて見えてくることが多いためです。

具体的には、レビューで指摘した内容を「なぜ指摘したか」まで含めてCLAUDE.mdに追記します。「命名規則が違う」だけでなく「既存のUserRepositoryパターンに合わせる」まで書くと、次回以降タイ・ラオスのメンバーが同じ指示を出しても再現できます。失敗ログは別ファイルかIssueテンプレートで蓄積し、月末にCLAUDE.mdへ反映する運用が現実的です。個人のチャット履歴に閉じたままだと、担当者が変わった瞬間にナレッジトランスファーが途切れます。

ルール文書を英語で統一するか、タイ語・日本語の注記を並記するかも、この段階で決めておくと後続のハーネス整備での書き直しが減ります。

指摘事項が数件程度の場合は文書化で足りますが、繰り返し同じ指摘が発生する場合はドキュメントだけでは防ぎきれません。ルールを人が読む文書からLinterやCIといった機械的な制約に移すことで、レビュー負荷を減らしつつ品質を安定させます。この段階ではハーネスエンジニアリングの考え方が中心になります。

CLAUDE.md に書いたルールは、読み手の解釈次第で運用がぶれやすいという弱点があります。「命名規則を守る」という一文があっても、AIコーディングエージェントがどこまで厳密に従うかは実行ごとに差が出るためです。この差を縮めるには、ルールをプリコミットフックとLinterの設定ファイルに移し、機械的に強制する仕組みへ落とし込みます。

具体的には、命名規則やインポート順序、未使用変数の検出はLinterに任せ、コミット前にフォーマッタとテストを自動実行するフックを組みます。CIではプルリクエスト作成時に静的解析とテストカバレッジのチェックを走らせ、基準を満たさない変更はマージ不可にします。これにより、Claude Codeが生成したコードも人間が書いたコードも同じ基準で評価され、レビュアーは設計判断やロジックの妥当性に集中できるようになります。

例外として、プロトタイプ用のブランチやドキュメント修正のみのコミットは、CIの一部チェックを緩和する運用も検討に値します。すべての変更に同じ厳格さを課すと、小さな修正のリードタイムが伸び、チームの離脱要因になりやすいためです。ハーネスエンジニアリングの要点は、守るべき基準を「書く」から「強制する」へ移す点にあります。ルールの棚卸しは月次で行い、頻発する指摘だけを機械的制約に格上げすると運用負荷を抑えられます。

タイ語話者、ラオス語話者、日本語話者が同じリポジトリで AI コーディングエージェントに指示を出すとき、どの言語で書けば意図が正確に伝わるでしょうか。

結論としては、CLAUDE.md やコミットメッセージのルール記述は英語に統一し、口頭やチャットでの補足指示は現地メンバーの母語を許容する二層構造が扱いやすい傾向があります。仕様や制約は英語で一元化する場合は X、日々のタスク依頼や質問は現地語でよい場合は Y という判断軸を持つと、翻訳コストと誤解のリスクを同時に減らせます。

タイ語・日本語・英語が混在する指示文をそのままプロンプトに渡すと、AIコーディングエージェントが構文を優先語として誤認し、変数名や出力形式が意図と異なるケースが報告されています。マルチリンガルNLPの精度は言語ごとに差があるため、重要な制約（命名規則・禁止事項・出力フォーマット）は英語で短く明文化し、背景説明や業務文脈は現地語で補足する分担が無難です。

レビューコメントも同様で、AIが生成したコードへの指摘は英語のテンプレートを用意し、現地メンバーが理解しにくい箇所だけ日本語やタイ語で注釈を加えると、レビュー基準の解釈違いを抑えられます。用語集を共有ドキュメントとして持ち、頻出技術語の対訳を揃えておくことも、指示の再現性を高める手段の一つです。

判断軸: 個人の工夫として使われてきたAIコーディングエージェントを、チーム標準として制度化できるかどうかです。

Day 61〜90 では、Day 1〜60 で積み上げたルールとハーネスを前提に、成果を数値で示す段階に移ります。レビュー指摘数やリードタイムなどのKPIで効果を可視化し、スキルやフックを個人資産からチーム資産へ移す作業が中心になります。

KPIを設計する場合は導入初期からの傾向比較が軸になり、絶対値の達成目標を掲げる場合は現場の実態とずれやすくなります。効果測定は「AIエージェント導入前と比べてどう変わったか」を追うのが基本です。

レビュー指摘数は、AIコーディングエージェントが生成したコードに対する差戻しコメントの件数を、Pull Request単位で記録します。導入直後は指摘が増える傾向がありますが、CLAUDE.mdやレビュー基準が浸透するにつれて減少するのが望ましい流れです。増加が続く場合は、ルール自体が現場の実装パターンと合っていない可能性を疑います。

リードタイムは、タスク着手からマージまでの時間です。定型実装やテストコードのように対象を絞ったタスクほど短縮効果が出やすく、複雑な仕様変更を含むタスクでは短縮しにくい傾向があります。タスクの種類別に分けて計測しないと、平均値だけでは判断を誤ります。

手戻り率は、マージ後に修正が発生した比率です。ここが高止まりする場合は、レビューで見逃しが起きているか、ハーネス側の制約が不十分な可能性があります。3指標は単独ではなく組み合わせて見ることで、AI ROI（AI投資対効果）の判断材料になります。KPIの継続的な設計手法はAIエージェント導入後の効果測定方法でも詳しく解説しています。

個人が試行錯誤して身につけたAIコーディングエージェントの使い方は、そのメンバーが離任した瞬間に失われます。90日目の時点で「あの人に聞かないと分からない指示の書き方がある」状態が残っているなら、チーム資産化がまだ済んでいないという合図です。

Agent Skillsとして切り出す対象は、繰り返し発生する定型作業に限定します。例えば、特定フレームワークでのAPIエンドポイント追加手順、タイ語・ラオス語を含む多言語文言のバリデーションパターン、テストコードの命名規則などです。個人のプロンプト履歴に埋もれていたノウハウを、誰が呼び出しても同じ結果になる形に整形し直します。

pre-commit hookやCI連携のフックも同様に、個々のローカル環境設定ではなくリポジトリに含めて共有します。ローカルLinterの設定を各自のPCに手動で入れる運用では、拠点間で設定がずれやすく、タイオフィスとラオスオフィスで検出されるエラーの種類が異なるといった事態が起きます。

資産化したSkillsとHooksは、CLAUDE.mdからの参照リンクを設け、更新時にはPull Requestでレビューを回します。担当者の異動や退職があっても、次のメンバーが同じ品質でAIエージェントを使い続けられる状態を目指します。

90日ロードマップを進めても、なぜ同じ失敗を繰り返すチームがあるのでしょうか。多くの場合、ツール導入とルール整備を同時に進めず、どちらかを後回しにしています。ここでは、ライセンス配布だけで終わる失敗と、駐在員止まりで現地メンバーに広がらない失敗を取り上げ、回避の考え方を示します。

判断軸: ライセンスを配って終わるか、ルールまで整えるかで定着度が変わります。

Claude Code のライセンスをチーム全員に配布した直後は、活用が広がったように見えることがあります。しかし CLAUDE.md やレビュー基準を整備しないまま使わせると、メンバーごとに指示の書き方やレビューの通し方が異なり、生成されたコードの品質にばらつきが出やすくなります。ある人は生成コードをそのままマージし、別の人は逐一書き直す、といった状態が起きると、チーム全体でのAI ROI（AI投資対効果）は測定しづらくなります。

回避策は、Day 1〜30 で決めたルールと Day 31〜60 のハーネスを、ツール配布と同時に周知することです。具体的には、CLAUDE.md への必須項目の記載、レビュー基準の明文化、pre-commit hook や CI での機械的な制約を先に用意してからライセンスを渡す順序が有効です。ツール配布とルール整備を分けて考えると、後からルールを追加しても浸透しにくく、各自のやり方が既に固まってしまいます。Claude Code チーム導入ガイドで紹介されている CLAUDE.md・Skills・Hooks の整備手順は、この順序を実践する際の具体的な参考になります。

日本人駐在員がClaude Codeを使いこなしていても、タイ語やラオス語を主言語とする現地エンジニアには広がらないケースが見られます。最初は「使い方を見せれば自然に浸透する」と考えがちですが、実際は現地メンバーが質問しづらい空気や、英語主体のドキュメントへの抵抗感を放置すると、ツールは駐在員の個人スキルのまま孤立してしまいます。

広げる鍵は、現地メンバーがレビュアー側に回れる状態をつくることです。CLAUDE.md やレビュー基準の初期案を駐在員だけで書き上げず、現地シニアエンジニアと一緒に見直す機会を Day 31〜60 の期間に設けると、ルールが現場の言葉と実務感覚に合ったものになりやすくなります。指示文のテンプレートをタイ語・ラオス語・英語のいずれでも書ける形にしておくことも有効です。

成果指標を測る段になって「使っているのは駐在員だけ」と判明すると、チーム標準化は形だけで終わります。KPI にはメンバーごとの利用頻度や、現地エンジニアが起案したルール改定の件数も加えておくと、定着の偏りを早期に把握できます。Claude Code チーム導入ガイドで紹介されているような、Skills を現地メンバー主導で育てる運用も参考になります。

Q1. Claude Codeの導入は何人規模のチームから始めるべきですか？ 規模そのものより、対象タスクを絞れるかが重要です。3〜5人程度の小さなチームで定型実装やテストコード生成から試し、CLAUDE.mdとレビュー基準を固めてから全体展開する流れが定着しやすい傾向があります。人数が多い場合も最初は一部チームに限定するとルール調整の負荷を抑えられます。

Q2. タイ語やラオス語の指示でも精度は落ちませんか？ 指示文の構造が曖昧だと言語を問わず精度が下がります。タイ語・ラオス語・英語が混ざる環境では、変数名やコミットメッセージのルールをCLAUDE.mdに明文化し、指示は短く条件を分けて書くことで誤解を減らせます。言語そのものよりドキュメントの整備状況が精度に影響します。

Q3. 90日で成果が出ない場合、何を見直せばよいですか？ まずKPIの設定が現場の実態と合っているか確認します。レビュー指摘数や手戻り率が改善しない場合、対象タスクの選定が広すぎるか、レビュー基準が現地メンバーに共有されていないケースが多く見られます。ハーネスやレビュー基準を Day 31〜60 の段階に戻して調整することも有効です。

Q4. 駐在員がいないチームでも同じロードマップは使えますか？ 使えます。むしろ最初から現地シニアエンジニアが主導する形になるため、ツールが個人スキルとして孤立しにくい利点があります。CLAUDE.mdの整備やレビュー基準の合意形成を現地メンバー主体で進める点は共通です。詳細な進め方はClaude Code チーム導入ガイド — CLAUDE.md・Skills・Hooks で開発ワークフローを標準化する方法も参考になります。

Q5. セキュリティやPDPA対応はどの段階で検討すべきですか？ 導入前の前提条件を揃える段階で検討しておくのが望ましいです。コードや設定情報に含まれる個人データの扱いは、タイのPDPAなど関連法令の観点からも早期に確認しておく必要があります。関連する実務チェックリストはタイのPDPA対応とAI活用を両立させるコンプライアンスチェックリストで整理しています。

90日でAIコーディングエージェントを定着させるには、何から手をつければ迷わずに済むのでしょうか。答えは規模の大小ではなく、順序を守ることにあります。

Day 1〜30では対象タスクを定型実装やテストコード生成に絞り、失敗をログに残しながらCLAUDE.mdを育てます。Day 31〜60では、そのルールをLinterやpre-commit hook、CIに移し、タイ語・ラオス語・日本語・英語が混ざる環境でも指示の解釈がぶれない状態を作ります。Day 61〜90では、レビュー指摘数やリードタイム、手戻り率といったKPIで効果を確認し、蓄積したスキルとフックをチーム資産として共有します。

途中でつまずきやすいのは、ツールだけ配ってルールを整えないケースと、駐在員だけが使い現地メンバーに広がらないケースです。いずれも「誰が最終的な品質を担保するか」を最初に決めておけば避けやすくなります。ロードマップの詳細な手順や標準化の具体例は、Claude Code チーム導入ガイドやハーネスエンジニアリングとは？でも確認できます。段階を飛ばさず積み上げることが、チーム全体への定着につながります。