エージェント型AIのコード生成リスクとフィリピン開発拠点のAI管理術

エージェント型AIがコード生成を解決した先に見えた本当の課題 — フィリピンに開発拠点を持つ日本企業のためのAI管理ガイド

フィリピンに開発拠点を持つ日本企業向けに、エージェント型AIで増えるコードをどう管理し、費用の暴走や品質低下を防ぐかを実務目線でわかりやすく解説します。

Part 1: このテーマが重要な理由

Step 1: フィリピンビジネスでの背景 (3分)

フィリピンは、英語が通じる人材が豊富で、ソフトウェア開発やBPO（海外の業務を受託する拠点のことです）が集まる国として知られています。多くの日本企業が、システム開発やコールセンター業務をフィリピンの拠点に任せています。

この記事が扱うのは、人の代わりに作業を自律的に進めるAI（"エージェント型AI"と呼ばれます）が、コードを書く作業を一気に速くした一方で、別の問題を表に出したという話です。コードを速く大量に作れるようになっても、製品の品質が同じ速さで良くなるわけではありません。本当に難しいのは、正しい要件を決めることや、複雑なシステムをつなぐこと、そして長く安全に運用することだからです。

フィリピンに開発チームを持つ日本企業にとって、これは身近な課題です。現地のチームがAIで大量のコードを生み出すと、それを確認する人の負担が一気に増えます。確認が追いつかなければ、障害や予想外の費用につながります。だからこそ、AIをどう管理するかをいま考える必要があります。

月曜の朝、マニラのオフィス。日本人マネージャーが、現地のIT責任者にこう切り出します。「先週、開発チームがAIで作ったコードの量、すごかったね。でも、レビューが間に合っていないみたいなんだ。この記事を読んでから、速さだけを追うのは危ないと感じてさ。一緒に管理のやり方を考えたいんだけど、いいかな」。IT責任者はうなずきながら、画面を一緒にのぞき込みます。

Step 2: 元記事の要点を整理する (5分)

元記事が示した事実と論点を、学習用に表へまとめました。

ポイント	元記事が示した内容
速くなったのはコード生成だけ	エージェント型AIで短縮できるのは実装そのものの手間にすぎず、何を作るべきかの見極めや、不具合が起きたときの責任の所在、稼働後の運用にかかる手間といった本来むずかしい部分はそのまま残ります
新しい難所は人間のレビュー	AIが生むコードが増えるほど、人が確認する作業が滞り、間違いを見つける力が落ちます
費用が暴走した実例（Uber）	Uberは2026年の予算を4月までに使い切り、AIへの支出に上限を設けました
1か月で5億ドルの請求	Axiosによると、ある企業はAIの処理が際限なく繰り返された結果、1か月でAnthropicへ5億ドルを請求されました
進め方は3つの段階	(1)費用と危機の管理、(2)技術の方針、(3)人材と組織、の順で整えることがすすめられています
AIには最小限の権限を	AIに人間と同じ強い権限をそのまま与えず、本番環境を変える操作には人の承認を必須にします
1社・1モデルに頼らない	得意分野は製品ごとに違うため、複数の提供元と複数のモデルを使い分けます
性能の高いモデルにお金をかける	安いモデルより、やり直しを減らす高性能なモデルのほうが結局は得になります
測る指標を変える	コードの行数ではなく、機能の定着や障害の発生率など、事業の成果につながる指標で測ります
急いで人を減らさない	AIによる成果を本番運用で実際に検証する前に人員削減へ踏み切るのは早計であり、自社に必要な人員規模を正しく把握できていない状態での判断だと警鐘を鳴らしています
出典: VentureBeat — 「Agentic AI solved coding — and exposed every other problem in software engineering」(2026年6月7日)
この表は学習目的で公開情報の事実をもとに作成したものです。詳細は上記リンクの元記事をご確認ください。

Step 3: 理解度チェック (5分)

Q1. 元記事によると、エージェント型AIが縮められないものは何でしょうか。3つ挙げてみてください。

ヒント: 作業時間は縮みますが、要件のあいまいさや責任、運用の複雑さは別の話です。

Q2. AIが生むコードが増えたことで、新しく生まれたボトルネック（作業が滞る場所）は何でしょうか。

ヒント: 人が手で行う、ある作業に注目してください。

Q3. Uberは2026年のAI予算について、どのような対応を取ったでしょうか。

ヒント: 予算を使い切った時期と、その後に設けたものを思い出してください。

Q4. AIに人間と同じ権限をそのまま与えてはいけない理由は何でしょうか。

ヒント: 権限と「責任を負う力」の関係を考えてみましょう。

Q5. 元記事は、人員を減らす前にやるべきことがあると述べています。それは何でしょうか。

ヒント: AIの効果を「どこで」確かめるべきか、という点が手がかりです。

Part 2: 実務への応用

Step 4: フィリピンでの導入ステップ (10分)

フィリピンの開発拠点でエージェント型AIを安全に使うための手順を、4つの段階にまとめました。

段階	やること	フィリピン特有の注意点
1. 費用の上限を決める	月ごとの利用上限と、開発用と本番用の予算枠を先に決めます	ペソ建てで予算を立て、為替の変動を見込んで少し余裕を持たせます。現地チームには「使い切ったら止まる」という前提を最初に伝えます
2. AIの権限を絞る	AIには読み取りだけを許し、本番を変える操作には人の承認を必須にします	フィリピンの個人情報保護法を所管するNPC（国家プライバシー委員会）の規則に沿い、個人データをAIが自由に扱わない設定にします
3. 確認する人を決める	誰がどのコードを確認するかを明文化し、確認の時間を業務時間に組み込みます	口頭での合意で終わらせず、必ず文書に残します。フィリピンでは口約束が後で食い違う場面があるためです
4. 成果で測る	コードの量ではなく、障害の発生率や機能の定着で評価します	現地の評価制度に合わせて説明し、評価が変わる理由をていねいに伝えます

Step 5: よくある失敗と対策 (5分)

失敗パターン1: 「速さだけを評価してしまう」

現地チームに「たくさんコードを書けば高評価」と伝えると、確認の薄い大量のコードが積み上がります。

NG例: マネージャーが週次の会議で、コードの行数や対応した件数だけを取り上げて褒めます。チームは量を増やすことに集中し、品質の確認が後回しになります。

OK例: 障害の発生率や、後から見つかった不具合の少なさを評価の中心にします。「速く、かつ壊れにくい」状態を目指すと、最初の会議で全員に伝えます。

失敗パターン2: 「AIに強い権限を渡したままにする」

便利だからと、AIに本番環境を変える権限まで与えてしまう失敗です。

NG例: 開発者が自分のアカウントの権限をそのままAIに使わせ、AIが本番のデータを書き換えてしまいます。誰が承認したのか分からず、責任の所在があいまいになります。

OK例: AIには読み取りだけを許します。本番を変える操作の前には、必ず人が内容を確認して承認する仕組みを入れます。

失敗パターン3: 「効果を確かめる前に人を減らす」

AIで速くなったからと、現地チームの人員をすぐに削ってしまう失敗です。

NG例: 経営層が「AIがあるから半分でいい」と判断し、確認や設計を担う人まで減らします。結果として障害が増え、対応が追いつかなくなります。

OK例: まずAIの効果を本番で数か月測り、どの作業に人手が要るかを確かめます。そのうえで、必要なら役割を組み替えていきます。

Part 3: さらに深く学ぶ

Step 6: 関連する技術用語 (5分)

エージェント型AI（Agentic AI／自律的に作業を進めるAI）は、人が一つひとつ指示しなくても、目標に向けて自分で手順を考えて実行するAIのことです。フィリピンの開発拠点では、テストの自動化やコードの下書きをこのAIに任せ、現地のエンジニアは設計や確認に時間を使う、といった使い方が広がっています。

最小権限の原則（Least Privilege／最低限の権限だけを与える考え方）は、人やAIに、その仕事に必要な最小限の権限しか渡さないという基本ルールです。マニラの開発チームでは、AIにデータの読み取りだけを許し、本番の変更は人が承認する形にすることで、思わぬ事故を防いでいます。

ヒューマン・イン・ザ・ループ（Human-in-the-loop／要所で人が判断に加わる仕組み）は、AIの作業の途中に人の確認を挟み、大事な操作は人が最終判断する仕組みです。フィリピンの拠点では、AIが書いたコードを本番に入れる前に必ず現地のリーダーが目を通す、という運用がこれにあたります。

マルチモデル戦略（Multi-model Strategy／複数のAIを使い分ける方針）は、1つのAIに頼らず、作業ごとに得意なAIを選んで使い分ける考え方です。たとえばマニラのチームが、文章の要約は別のAI、コード生成はまた別のAIに任せるようにすると、止まったときの影響を小さくできます。

技術的負債（Technical Debt／後で支払うことになる開発上の借金）は、その場しのぎで書いたコードが後で大きな手直しを生む状態を、借金にたとえた言葉です。フィリピンの拠点でAIに任せきりにすると、見た目は動くが直しにくいコードがたまり、後の保守で時間と費用がかさむ原因になります。

Step 7: 自社への応用を考える (10分)

自社のAI費用がどこまで膨らむかを見える化する

考えるヒント: 自社の開発チームが今どれくらいAIを使い、月にいくら払っているかを把握できていますか。Uberのように予算を使い切る前に、上限を決めておく必要はないでしょうか。

AIの権限と「責任の所在」を整理する

考えるヒント: いま自社のAIは、どこまでの操作を自分でできる状態でしょうか。本番を変える操作の前に、人の承認が入る仕組みになっているか確認してみましょう。

現地チームの評価の仕方を見直す

考えるヒント: 自社では、コードの量で人を評価していないでしょうか。事業の成果や、障害の少なさで測るとしたら、どんな指標が合うかを話し合ってみてください。

次のアクション: まずは自社のAI利用について、月ごとの費用と利用上限を1枚の表にまとめ、来週の会議で関係する部署と共有してみましょう。

Part 4: FAQ

Q1. フィリピンの小さな開発チームでも、ここまでの管理体制は必要でしょうか。

規模が小さくても、費用の上限とAIの権限の2点だけは先に決めておくことをおすすめします。元記事のように1か月で多額の請求が発生する事故は、チームの大小に関係なく起こりうるからです。最初は簡単な表で十分なので、まず費用と権限から始めましょう。

Q2. 日本本社とフィリピン拠点で、AIのルールは統一すべきでしょうか。

基本の方針は本社でそろえつつ、現地の事情に合わせて細かい運用は調整するのが現実的です。フィリピンには独自の個人情報保護法があり、データの扱いは現地の規則に沿う必要があります。共通のルールを示したうえで、現地の判断で動かせる範囲を明確にしておきましょう。

Q3. 現地チームに「人を減らさない」と伝えても、不安は残りませんか。

AIで役割が変わることを、減員ではなく成長の機会として伝えるのが効果的です。コードを書く作業から、設計や確認を担う役割へ移ってもらう、という具体的な道筋を示しましょう。フィリピンでは将来の見通しを示すと安心につながりやすく、定着率の向上にもつながります。

Q4. AIへの費用は、ペソと日本円のどちらで管理すべきでしょうか。

現地での実際の支払いはペソで発生するため、現地チームにはペソ建ての上限を示すと分かりやすくなります。一方で本社への報告は日本円でまとめ、為替の変動も見込んでおきましょう。両方の通貨で並べて管理すると、認識のずれを防げます。

Q5. AIが書いたコードのミスは、誰が責任を負うのでしょうか。

最終的な責任は、そのコードを承認して本番に入れた人が負います。だからこそ、AIに承認まで任せず、人の確認を挟む仕組みが大切です。フィリピンでは口頭の合意で終わらせず、承認の記録を文書に残しておくと、後の食い違いを防げます。

活用のコツ(3 Tips)

まず「費用の上限」と「AIの権限」の2点だけを今週決める すべてを一度に整えようとすると動き出せません。元記事が示した費用の暴走と権限の事故は、この2点を先に押さえるだけで大きく減らせます。簡単な表で構わないので、まず着手しましょう。

コードの量を褒めるのをやめ、障害の少なさを評価の中心に置く 量を評価すると、確認の薄いコードが積み上がります。週次の会議で取り上げる指標を、行数から障害の発生率へ切り替えてみてください。チームの動き方が変わります。

人を減らす判断は、AIの効果を本番で数か月測ってから行う 速くなったからとすぐ人員を削ると、確認や設計が回らなくなります。まず効果を本番で確かめ、どの作業に人手が要るかを見きわめてから、役割の組み替えを検討しましょう。

ボーナス: PH AI Worksの活用法

PH AI Worksは、フィリピンでのAIやテクノロジーの活用を支援する企業です。今回のテーマである「エージェント型AIの安全な導入と管理」について、現地の事情を踏まえたお手伝いができます。

次のステップとして、たとえば以下のような内容をご相談いただけます。

フィリピン拠点でのAI利用について、費用の上限や権限の決め方を一緒に整理する
AIが書いたコードを確認する体制づくりや、現地チームの役割の見直しを支援する
フィリピンの個人情報保護法に沿った、AIのデータの扱い方を確認する

まずはお気軽にお問い合わせください。