「もっとやりたいことがあるのに、今のスピードでは足りない。」
これが、AI社員を導入する前の私の一番の悩みだった。
2025年6月、マレーシアに拠点を移した。オフショア開発を目的に、現地エンジニアと一緒にシステム開発を進める体制を作るためだ。しかし半年後、当初の想定とは全く違う形で仕事をしている自分がいた。
本記事では、ローカルエンジニアとの協業から、AI社員チーム体制に至るまでの全過程を、Phase 0-5のロードマップとして振り返る。
Phase 0：オフショア開発体制の構築
マレーシアに来た当初の計画はシンプルだった。
- 日系企業からシステム開発を受注する
- 要件定義・設計は私が担当する
- 実装はローカルエンジニアに任せる
いわゆるオフショア開発の王道パターンだ。依頼の内容も、ホームページやLPなど比較的シンプルなものが多く、AIを使うまでもない案件がほとんどだった。
マレーシアで仕事をして感じた日本との大きな違いがある。目的がはっきりしていることだ。
マレーシアに来ている日系企業の目的は明確で、「マレーシアで成功して実績を作る」——おおむねこれに尽きる。目的がはっきりしている分、こちらの提案も仕事内容も迷いが少ない。無駄な会議、無駄な根回しが減る。この「目的の明確さ」が、後のAI活用を加速させる土壌になった。
Phase 1：ChatGPTからClaude Codeへの移行
日本にいた頃からChatGPTは使っていた。メールの下書き、技術的な壁打ち、アイデアのブレスト。正直、最初の感想は「すごいけど、仕事の根幹は変わらない」だった。回答はそのまま使えないケースが多く、結局人間が加工・修正する工程が必要だった。
転機はコーディング品質だった。
ChatGPTのコード生成は部分的なスニペットが中心で、プロジェクト全体を通した一貫性のある実装は難しかった。Claude Codeに切り替えたとき、明確な差を感じた。
- ファイルシステムに直接アクセスして実装できる
- プロジェクトの文脈を理解した上でのコーディング
- 設計書に基づく一貫性のある実装
ただし、ここで強調しておきたいのは、AIツールの優劣は急速に変化するという点だ。2026年2月時点での判断であり、半年後には状況が変わっている可能性がある。重要なのはツール選定そのものではなく、AIを業務プロセスに組み込む設計力だ。
Phase 2：依頼増加が転換点になった
マレーシアでの仕事が軌道に乗り、依頼が増え始めた。ホームページ、LP、業務システム——案件の数も種類も増えていく。デザインと設計のスピードが追いつかなくなった。
ここで、AIの使い方が根本的に変わった。
ミーティング中にモックを生成する
ミーティング中に、要件と設計、デザインまで入れたモックをAIで生成する。
これが、営業スタイルを劇的に変えた転換点だ。
従来のフローはこうだった。
- 初回ミーティング（ヒアリング）
- 要件整理（1-2日）
- デザイン案作成（3-5日）
- 確認ミーティング
- 修正（2-3日）
- 実装開始
AI導入後はこうなった。
- ミーティング中に要件ヒアリング + モック生成
- その場でフィードバック → 即修正
- 実装開始
数週間かかっていた工程が、1-2回のミーティングに圧縮された。
なぜこれが機能するのか：「言語化の壁」を壊す
要件定義とは、クライアントの頭の中にある曖昧なイメージを、開発可能な仕様に落とし込む作業だ。システム開発の経験がないクライアントにとって、「こういうシステムが欲しい」を正確に言葉にするのは非常に困難だ。
しかし、見た目や動くものがあれば、言語化のハードルは劇的に下がる。
「こんな感じのサイトです」とモックを見せれば、クライアントは「ここをもう少しこうしたい」「この機能はいらない」と具体的にフィードバックできる。深い言語化をせずに、正確な意思疎通ができる。
さらに進化して、初回ミーティングの前に3つのデザイン案を作成して提示する方法も確立した。クライアントは「この方向性がいい」と選ぶだけでいい。最短では、ミーティングなしで実装完了するケースも出てきた。
普通であれば、ミーティング前に3案もモックを作る余裕はない。工数的にありえない。しかし、AIと一緒なら数時間で3案を仕上げられる。
Phase 3：「ツール」から「チームメンバー」への転換
依頼が増え、AIの活用が深まる中で、ノウハウやコンテキストが固まってきた。ここで「ツールとして使う」から**「チームメンバーとして組織化する」**に転換した。
自分の業務を棚卸しした結果、必要な役割が4つに分類できた。1人で全部やっていた時代、無意識に「PM」「マーケ」「戦略」「開発」の4つの帽子を被り替えていたことに気づいた。それを明示的に分離し、それぞれにAI社員を配置した。
AI社員の詳細な役割定義や実際の稼働データはAI社員の実稼働レポートで公開している。
エージェント化への進化
運用を続ける中で、さらにノウハウが蓄積された。現在ではClaude Codeのskills機能を活用し、各AI社員の専門知識やワークフローをコード化している。毎回ゼロから指示するのではなく、蓄積されたスキルセットに基づいて自律的に動く仕組みだ。
これにより、指示の精度が上がり、出力の品質も安定してきた。
Phase 4：業務量3倍の現在地
AI社員チームを組んだ現在。よく「楽になりましたか？」と聞かれるが、答えはノーだ。
「1/3にする」のではなく「3倍にする」
AI導入で生まれた余裕を「楽をする」ために使うのではなく、もっと多くの仕事を引き受けるために使っている。結果として、以前と変わらない忙しさだ。
しかし、数字で見ると景色は違う。同時進行案件数は2-3件から5件以上に増え、コンテンツ発信は月1-2本から週3-5本に拡大した。月間追加コストは3-5万円。同じ「忙しい」でも、アウトプットの量と質が全く違う。
AI導入前後の詳細な比較データと5案件同時進行の具体的なノウハウは1人のPMが5案件を同時進行する方法で解説している。
Phase 5：やってはいけないこと——失敗から学んだ教訓
AI活用を進める中で、痛い失敗もしてきた。これからAIチームを組む方が同じ轍を踏まないよう、具体的に記録しておく。
1. AIへの丸投げで品質事故を起こす
初期の頃、自社サービスの機能追加をClaude Codeに丸投げしたことがある。「この機能を実装して」とだけ伝え、出力されたコードをほぼレビューせずにデプロイした。結果、エッジケースの処理が抜けており、特定の条件でデータが正しく保存されないバグが本番に出た。
教訓：AIの出力は必ずレビューする。特に本番環境に出すコードは、テストカバレッジとエッジケースの確認を怠らない。
2. 指示の解像度が低いまま進める
「いい感じのデザインで」「適切な技術選定で」——こうした曖昧な指示をAIに出すと、AIは「それらしい」出力を返す。しかし、「それらしい」は「正しい」ではない。ある案件で、AIが選定した技術スタックが案件の非機能要件（同時接続数、レスポンス時間）を満たせないことが後から判明し、設計のやり直しが発生した。
教訓：AIへの指示は「何を」「なぜ」「どのような制約で」を明確にする。指示の解像度が、そのまま出力の品質になる。
3. レビューを省略して工数を「節約」する
忙しい時ほど、AIの出力をそのまま採用したくなる。しかし、コードレビューを省略して「節約」した時間は、後のバグ修正で3倍になって返ってくる。特にセキュリティ関連のコード（認証、権限管理、入力バリデーション）は、AIが一見正しいコードを生成しても、微妙な脆弱性が潜んでいることがある。
教訓：レビューは「コスト」ではなく「投資」。省略して得られる時間より、省略して失う信頼の方が大きい。
4. AIの得意・不得意を見極めない
AIはコード生成やデータ処理には強いが、ビジネス判断や顧客の感情理解は苦手だ。あるクライアントへの提案資料をAIに作らせたとき、技術的には正確だが、クライアントの組織文化や意思決定プロセスへの配慮が欠けた内容になった。提案は通らなかった。
教訓：AIに任せる領域と人間が担う領域の線引きを常に意識する。特に対人コミュニケーションが関わる領域は、AIの出力をそのまま使わない。
5. 継続的な改善を怠る
AI社員の運用が安定すると、「これでいい」と思いがちだ。しかし、AIツールは急速に進化しており、半年前の最適解が今の最適解とは限らない。プロンプトの改善、新機能の活用、ワークフローの見直しを怠ると、AIの潜在能力を活かしきれない。
教訓：AI社員の運用も、人間のチームと同じくPDCAを回す。月1回は運用方法を見直す時間を設ける。
1人社長がAIチームを組むためのロードマップ
私の経験を、再現可能なステップにまとめる。
Step 1：まず1つの業務で試す
いきなりAI社員チームを組む必要はない。まずは1つの業務でAIの効果を体感する。おすすめはクライアント向けのモック作成。目に見える成果が出やすく、クライアントの反応も即座にわかる。
Step 2：クライアントとの接点にAIを組み込む
AIを「裏側の作業」だけでなく、クライアントとの接点に組み込む。ミーティング中のモック生成がその典型だ。Phase 2で紹介した方法を、自分の業種に合わせてアレンジしてほしい。
Step 3：ノウハウを蓄積して役割を定義する
何件かの案件でAIを活用すると、パターンが見えてくる。そのパターンを役割として明確化し、AI社員を設計する。自分が無意識に被り替えている「帽子」は何か。その棚卸しから始める。
Step 4：エージェント化で自律性を高める
Claude Codeのskillsなどを活用し、AI社員のワークフローをコード化する。毎回同じ指示を出す手間が減り、品質も安定する。
Step 5：業務量を増やす
AIで生まれた余裕を、もっと多くの仕事に向ける。楽をするのではなく、成長のために使う。
ただし、ここで1つ注意がある。業務量を増やすことが目的ではない。自分が「やりたいこと」「届けたい価値」が増えた結果として業務量が増える、という順序が健全だ。AIによる効率化を「もっと稼ぐ」ためだけに使うと、本質を見失う。
まとめ
オフショア開発からAIチーム体制へ。想定していなかった形で、しかし確実に仕事の進め方は進化した。
この進化を振り返って、最も重要だったのはPhase 2のミーティング中モック生成だ。AIを「裏方の効率化ツール」から「クライアントとの価値共創のパートナー」に昇格させた瞬間が、すべての転換点だった。
AI社員は万能ではない。丸投げすれば品質事故が起き、指示が曖昧なら出力も曖昧になる。しかし、適切な役割設計と運用改善を続ければ、1人の限界を大きく超える成果を出せる。
「もっとやりたいことがある」——その思いがあるなら、まずはPhase 1から始めてみてほしい。
AI社員の実際の稼働データはAI社員の実稼働レポートで公開しています。AI活用で経験した失敗と教訓の詳細はAI活用で痛感した失敗と教訓をご覧ください。
PMBOK-AIの詳細はPMBOK-AIとはで、5案件同時進行の体制については1人のPMが5案件を同時進行する方法で解説しています。
AI社員の導入やチーム構築についてのご相談はお問い合わせからお気軽にどうぞ。