English below.

開発の”主導権”は、どこにあるべきか

METABIRDSの「AI活用・自社開発支援サービス」が向き合う問い

ChatGPTやClaudeで文章を書き、Claude CodeやCursorでアプリを組み立てる。こうしたことが、エンジニアでなくてもできるようになりました。だとすれば、次に企業が向き合う問いは「AIを使うかどうか」ではありません。「何を作るか、どのシステムを持つか、どう改善するかを、誰が決めるのか」という、開発の主導権の所在です。

METABIRDS（株式会社メタバーズ）が提供する「AI活用・自社開発支援サービス」は、この問いに答えるためのサービスです。AIツールの活用支援で終わらせず、SaaSの見直し、社員とAIによる自社開発、既存システムの引き継ぎ、必要な部分の共同開発、本番運用までを、企業が主導権を持ったまま進められるよう支援します。

https://aidev.metabirds.com/

なぜ今、この問いが重要になっているのか

背景には、方向の異なる二つの変化が重なっています。

一つは、IT人材の不足です。経済産業省が2019年に公表した「IT人材需給に関する調査」によると、2030年には最大で約79万人、中位シナリオでも約45万人のIT人材が不足すると試算されています。人を増やして解決する、という前提そのものが崩れつつあります。実際、IPA（情報処理推進機構）の「DX動向2024」では、DXを推進する人材の「量」が大幅に不足していると回答した企業の割合が、2021年度の30.6%から2024年度には62.1%へと、3年でほぼ倍増しています。

もう一つは、SaaSの増殖です。Okta Japanの年次レポート「Businesses at Work 2025」によると、日本企業1社あたりの平均導入アプリ数は46個で、前年比31%増と、調査対象国の中で最も高い成長率を記録しました。部署ごとに便利なSaaSを導入した結果、どれを使い続け、どれをやめ、どれを自社のシステムでつなぐべきかを、誰も横断的に判断できていない、という状態が広がっています。

人を増やせない。ツールは増え続ける。この板挟みのなかで、「AIを使えば社員でも作れる」という選択肢が現実的になったことは朗報です。しかし同時に、これはSaaSの増殖とまったく同じ構図を、もう一段深いところで繰り返すリスクでもあります。

想像してみてください。営業部がChatGPTに顧客リストを貼り付けて提案書を書かせる。経理部がClaudeに見積データを読み込ませて簡単な集計ツールを作る。開発が得意な若手社員が、週末にClaude CodeやCursorで小さな社内ツールを組み上げて「勝手アプリ」として現場に配る。どれも、誰かに相談する必要すらありません。ブラウザとアカウントさえあれば、その日のうちに動くものができてしまいます。そして半年後、隣の部署が同じ課題を別のAIツールで解決していたことに気づく。ツールを作った本人が異動・退職すると、誰も中身を把握していないブラックボックスだけが残る。個人のクレジットカードに紐づいたAPIキーが、退職後もそのまま動き続ける——こうしたことは、特別な話ではなく、AIで「誰でも作れる」ようになった以上、十分に起こり得る話です。

これは想像だけの話ではありません。IPA（情報処理推進機構）が2026年1月に公表した「情報セキュリティ10大脅威 2026」では、組織向けの脅威として「AIの利用をめぐるサイバーリスク」が初めてランクインし、3位に入りました。エルテスが2026年1月に実施した調査（会社員・公務員300名対象）では、業務で生成AIを使っている人は34.3%にのぼり、そのうち少なくとも約5人に1人が、会社が許可していないツールを使っていたと回答しています。ガートナージャパンが2026年6月に公表した国内エンドユーザー調査では、73%の企業が「シャドーAI」（会社が把握・許可していない生成AI利用）を有効に管理できておらず、内訳は43%が実態すら把握できておらず、30%は把握していても対策が取れていない、というものでした。一方で75%の企業は、IT部門が選定していない生成AIツールの利用を、自由に、あるいは審査の上で容認してもいます。「使わせない」という選択肢は、すでに現実的ではなくなっているということです。

この構図がどこに行き着くかを示す実例もあります。クラウド開発基盤を提供する米Vercelは、2026年4月、内部システムへの侵入を公表しました。発端は、従業員が業務で使っていた第三者のAIツールが何者かに侵害されたことです。そのツールに紐づいていたGoogle WorkspaceのOAuth連携（外部サービスに社内アカウントの権限を与える仕組み）が乗っ取られ、攻撃者はそこを経由してVercelの内部システムに侵入し、APIキーを含む一部の顧客データを閲覧しました。従業員が「便利だから」と一つのAIツールを業務に接続しただけで、会社のシステム全体につながる入口になり得るということを、この事例は具体的に示しています。

つまり、何を自社で持ち、何を任せるかを判断する役割は、AIを導入するだけでは埋まりません。むしろAIが「誰でも作れる」入口を開いたからこそ、何をどこまで現場の裁量に任せ、どこから先は設計・レビュー・セキュリティの目を通すのか、という判断を、誰かが意識的に担う必要が出てきています。

「動く」と「安全に拡張できる」は、別の話

シャドーAIが情報漏えいの入口になるという話とは別に、もう一つ、方向の異なるリスクがあります。ITスキルの高くない社員がAIと一緒に作ったアプリは、多くの場合「動く」ところまでは驚くほど簡単にたどり着きます。しかし、そこから先――複数人で同時に使う、複数の取引先・部署にサーバー越しに使わせる、といった段階に進んだ瞬間に、目に見えなかった設計上の欠陥が一気に露出します。

一人で使う分には、状態はブラウザのタブの中だけで完結し、データが混ざる相手もいません。ところが同時アクセスを想定していないと、複数人が同時に保存ボタンを押した瞬間にデータが上書きされる、片方の入力が消える、といった不具合が起こります。さらにマルチテナント化――複数の顧客・部署のデータを一つのシステムで扱う設計に進もうとすると、テナントごとのデータ分離や権限管理という、最初から設計に組み込んでおくべき要素が抜け落ちていることが表面化します。悪くすると、Aさんの会社の画面に、Bさんの会社のデータが表示されかねません。

これは特殊な話ではなく、実際に広く観測されている失敗パターンです。プログラミング教育を手がけるShiftBが自社の受講生を対象に行った調査では、AIとの対話だけでコードを書く「バイブコーディング」で作られたプロジェクトのうち89%がテストコードを持っていませんでした。同社は、開発環境やユーザー数人の段階ではほとんどのアプリが問題なく動くものの、ユーザーが100人、1,000人と増えた段階で問題が顕在化すると指摘しています。同社が公開した2026年3月時点のデータでは、AIが生成したコードの脆弱性件数（CVE登録件数）は、1月の6件から3月には35件以上へと急増し、前年比では2.74倍に増えたとされています。

ShiftBが受講生から実際に聞いたという例では、バイブコーディングで3日かけて作ったECサイトが、開発の前半と後半でデータベース設計が矛盾しており、修正しようにも依存関係が複雑に絡み合って手をつけられなくなった、というケースが報告されています。最終的には作り直しになったといいます。ここで重要なのは、「AIがコードを書くのが遅かったから」失敗したのではないということです。最初の設計判断が誤っていたために、AIがどれだけ速くコードを生成しても、直すたびに別の場所が壊れる、という状態から抜け出せなくなったのです。

これが、「AIとのデスマーチ」とでも呼ぶべき状態です。不具合が見つかる。AIに修正を依頼する。直った直後に、別の場所で新しい不具合が発生する。AIは指示されたことを驚くほど速くこなしますが、土台となる設計そのものが崩れていれば、AIの速さはそのまま「間違った方向へ速く進む」ことにしかなりません。人間のエンジニアがこのループにはまっても抜け出すのは大変ですが、AIが相手をしてくれる分だけ延々と挑戦し続けられてしまう、という意味では、以前より抜け出しにくいループとも言えます。

つまり、「誰が作るか」を広げたAIコーディングの恩恵を、実際に業務で使える形に持っていけるかどうかは、ほとんどの場合、コードを書く速さではなく、最初の設計判断にかかっています。同時アクセスをどう扱うか、テナントをどう分離するか、権限をどう設計するか――これらは、動くプロトタイプができあがった後からでは手遅れになりやすい判断です。

誰が何を担うか、を最初に整理する

「AI活用・自社開発支援サービス」の設計は、AIを導入することそのものではなく、社員・AI・METABIRDSの役割分担を最初に整理する、という点に集約されます。

社員は、業務知識と優先順位の判断を持ちます。AIは、コード生成やドラフト作成、調査・要約を高速化する道具として使われます。METABIRDSは、設計・技術判断、コードレビュー、セキュリティ、本番化を担当し、必要であれば実装そのものにも加わります。この三者の役割を最初に整理することで、「開発の主導権は自社に残したまま、難しいところだけプロに任せる」という状態をつくります。

既存のSaaSやシステムをどう扱うかについても、同じ考え方が貫かれています。標準的な業務はSaaSを使い続け（KEEP）、AIやAPIでシステム同士をつなぎ（CONNECT）、企業固有の競争力に関わる部分は自社で作り（BUILD）、老朽化したシステムは置き換える（REPLACE）。「SaaSをやめて全部自社開発にすべきだ」とは煽らず、業務ごとに中立に判断する枠組みを使います。

なぜ、この支援の形が今できるようになったのか

「AIで自社開発する」という選択肢自体は新しいものですが、それを安全に支える体制は、一朝一夕にはできません。METABIRDSがこの支援を提供できる背景には、積み重ねてきた技術の層があります。

同社は2012年からチャットボットの開発・運用を続けてきました。そこから、外部システムとの連携、生成AIとの連携、ナレッジ検索・文書参照のためのRAG（検索拡張生成）、自律的に動くAIエージェント、そして最新の連携プロトコルであるMCP（Model Context Protocol）へと、対応する技術を発展させてきています。

この積み重ねが意味するのは、AIコーディングツールが登場する以前から、「AIと会話しながら動くシステム」を設計・運用してきた経験があるということです。ChatGPTやClaude Codeが、非エンジニアでもコードを書ける入口を開いた一方で、そのコードを本番環境で安全に動かし、セキュリティを確保し、運用を続けるという層は、AIツールの進化だけでは自動的には埋まりません。METABIRDSは、AIが得意なプロトタイピングの層と、長年の運用で培った本番化・セキュリティの層の両方に足場を持つことで、「全部を自社で抱えなくても、小さく始められる」支援を成立させています。

途中から始めても、任せられる

もう一つの特徴は、ゼロからの開発だけを対象にしていないことです。バイブコーディングで作った試作品、社内で開発したAI、他社が構築したシステムであっても、まずコード・環境・ライセンス・ドキュメントなどを確認し、引き継ぎの可否と必要な改善量を評価するところから始められます。「誰が作ったか」ではなく「今どういう状態にあるか」を起点にする設計です。

セキュリティ面では、国際標準のISMSセキュリティ認証ISO27001:2022に基づく体制を敷いており、食品業界の上場企業やゲーム業界の大手企業など、情報管理の水準が求められる企業でも利用されています。

まとめ

AIコーディングツールは、「誰が作るか」の選択肢を広げました。しかし、それは「何を作るべきか」「どこまで自社で持つべきか」という判断まで自動的に行ってくれるわけではありません。IT人材が構造的に不足し、SaaSが放っておいても増え続ける環境では、この判断を誰かが意識的に担う必要があります。

「AI活用・自社開発支援サービス」が提供しているのは、コードを書く力そのものではなく、社員・AI・専門家のあいだで開発の主導権をどう配分するかという設計です。AIに何を任せ、どこからをプロに預けるかは、状況によって変わります。だからこそ、初期3か月で現状を整理し、優先タスクに着手し、継続の道筋を合意する、という段階を踏む形になっています。

まずは今の状況を聞かせてほしい、というのが、このサービスの出発点です。

AI活用・自社開発支援サービス by METABIRDS　https://aidev.metabirds.com/

出典
  • 経済産業省「IT人材需給に関する調査」（2019年4月公表）
  • IPA（独立行政法人情報処理推進機構）「DX動向2024」
  • IPA（独立行政法人情報処理推進機構）「情報セキュリティ10大脅威 2026」（2026年1月29日公表）
  • Okta Japan「Businesses at Work 2025」
  • 株式会社エルテス、生成AI利用実態調査（2026年1月19日発表）
  • ガートナージャパン、国内エンドユーザー向けシャドーAI調査（2026年6月18日発表）
  • Vercel公式セキュリティ速報（2026年4月19日公表）
  • ShiftB「バイブコーディングの限界と落とし穴」「バイブコーディングの失敗パターン7選と対策」（受講生142名を対象とした自社調査、2026年3月〜4月公開）
  • 株式会社メタバーズ「AI活用・自社開発支援サービス by METABIRDS」公式サイト（https://aidev.metabirds.com/）

Who Should Hold the Reins of Development?

The question behind METABIRDS’ “AI Adoption & In-House Development Support”

People who aren’t engineers can now write copy with ChatGPT or Claude, and assemble working apps with Claude Code or Cursor. If that’s true, the question companies face next isn’t “should we use AI.” It’s “who decides what gets built, what systems we own, and how we improve them” — in other words, who holds the reins of development.

METABIRDS Co., Ltd.’s “AI Adoption & In-House Development Support” service exists to answer that question. It doesn’t stop at helping companies adopt AI tools — it supports reviewing existing SaaS, in-house development done by employees working with AI, taking over existing systems, joint development where needed, and production operations, all while keeping the company itself in control.

https://aidev.metabirds.com/

Why This Question Matters Now

Two shifts, pulling in different directions, are converging.

The first is a shortage of IT talent. Japan’s Ministry of Economy, Trade and Industry (METI) estimated in its 2019 “Survey on IT Talent Supply and Demand” that by 2030, Japan will face a shortfall of up to roughly 790,000 IT workers, or around 450,000 under a mid-range scenario. The assumption that this can be solved by hiring more people is breaking down. Indeed, according to IPA’s (Information-technology Promotion Agency, Japan) “DX Trends 2024,” the share of companies reporting a severe shortage in the “volume” of DX talent nearly doubled in three years, from 30.6% in FY2021 to 62.1% in FY2024.

The second is the proliferation of SaaS. According to Okta Japan’s annual “Businesses at Work 2025” report, the average number of apps deployed per company in Japan reached 46 — up 31% year over year, the highest growth rate among the countries surveyed. As each department adopts whatever SaaS is convenient, no one ends up with a cross-departmental view of what to keep using, what to retire, and what should be connected through an in-house system instead.

Companies can’t hire their way out of this, and the tools keep multiplying. Against that backdrop, it’s good news that “employees can now build things themselves with AI” has become a realistic option. But at the same time, this risks repeating the exact same pattern as SaaS sprawl — one level deeper.

Picture it concretely. Sales pastes a customer list into ChatGPT to draft a proposal. Accounting feeds estimate data into Claude to build a quick tally tool. A developer-minded junior employee spends a weekend putting together a small internal tool with Claude Code or Cursor and hands it out informally to the team. None of this requires asking anyone. All it takes is a browser and an account, and something working exists by the end of the day. Six months later, someone notices that the department next door solved the exact same problem with a different AI tool. The person who built the tool moves teams or leaves the company, and what’s left is a black box nobody understands. An API key tied to someone’s personal credit card keeps quietly running after they’ve gone. None of this is exotic — once “anyone can build it” with AI, it’s a plausible outcome.

This isn’t just hypothetical. In January 2026, IPA published its “10 Major Threats to Information Security 2026,” and for the first time, “cyber risk around AI use” entered the organizational threats ranking — in 3rd place. In a January 2026 survey of 300 company employees and public servants, Eltes Co., Ltd. found that 34.3% use generative AI at work, and at least roughly one in five of them said they use tools their employer hasn’t authorized. In a domestic end-user survey published in June 2026, Gartner Japan found that 73% of companies cannot effectively manage “shadow AI” (generative AI use their organization hasn’t identified or approved) — broken down, 43% can’t even grasp the actual state of use, and 30% are aware of it but haven’t been able to act on it. Meanwhile, 75% of companies already tolerate — freely, or after some review — the use of generative AI tools that IT hasn’t vetted. Simply refusing to let employees use AI is no longer a realistic option.

There’s a concrete example of where this pattern leads. In April 2026, Vercel, the U.S. cloud development platform provider, disclosed an intrusion into its internal systems. The point of entry was the compromise of a third-party AI tool an employee used for work. The Google Workspace OAuth connection tied to that tool — a mechanism that grants an external service access to an internal account — was hijacked, and attackers used it to reach Vercel’s internal systems, where they viewed some customer data, including API keys. This incident shows concretely how one employee connecting a single AI tool to their work, simply because it was convenient, can become an entry point into an entire company’s systems.

In short, deciding what a company should own itself and what it should hand off doesn’t get resolved just by adopting AI. If anything, precisely because AI has opened up a door where “anyone can build it,” someone now needs to consciously decide how much to leave to individual discretion in the field, and at what point design review, code review, and security need to get involved.

“It Works” and “Safe to Scale” Are Different Things

Separate from shadow AI as an entry point for data leaks, there’s another risk that runs in a different direction. An app that a lower-skilled employee builds together with AI usually gets to “it works” astonishingly fast. But the moment it moves past that point — multiple people using it at once, or multiple departments or business partners using it over a server — design flaws that were invisible before suddenly surface all at once.

Used by one person, the app’s state lives entirely inside a single browser tab, and there’s no one else’s data to collide with. But if concurrent access was never designed for, the moment two people hit “save” at the same time, one person’s input gets silently overwritten or lost. Push further into multi-tenancy — one system handling data for multiple customers or departments — and the things that needed to be designed in from the start, like per-tenant data isolation and access control, turn out to be missing. In the worst case, Company A’s screen ends up showing Company B’s data.

This isn’t a rare, exotic pattern — it’s one that’s been widely observed. In a survey of its own students, ShiftB, a company that runs programming courses, found that 89% of projects built through “vibe coding” (writing code entirely through conversation with AI) had no test code at all. The company notes that in a development environment, or with just a handful of users, almost every app runs fine — the problems surface once user counts climb into the hundreds or thousands. In data ShiftB published as of March 2026, the number of security vulnerabilities (CVE registrations) found in AI-generated code jumped from 6 in January to over 35 in March — a 2.74x year-over-year increase, by the company’s account.

In one case ShiftB reports hearing directly from a student, an e-commerce site built through vibe coding in three days ended up with a database design that contradicted itself between the first and second halves of development; when the student tried to fix it, the dependencies were so tangled that nothing could be untangled without a full rebuild. What matters here isn’t that the project failed because “AI wrote code too slowly.” The original design decision was wrong, so no matter how fast AI generated code afterward, every fix just broke something else — and there was no way out of that state.

Call this an “AI death march.” A bug turns up. You ask AI to fix it. The moment it’s fixed, a new bug appears somewhere else. AI executes instructions astonishingly fast — but if the underlying design is broken, that speed just means moving fast in the wrong direction. A human engineer stuck in this loop eventually has to stop and rethink; with AI willing to keep trying indefinitely, it’s arguably a harder loop to escape than before.

In other words, whether the benefit of AI coding — widening who can build something — actually turns into something usable in production usually comes down not to how fast the code gets written, but to the design decisions made at the very start. How concurrent access gets handled, how tenants get isolated, how permissions get designed — these are judgments that are easy to make too late, after a working prototype already exists.

Sorting Out Who Owns What, First

The design of “AI Adoption & In-House Development Support” comes down to one thing: rather than starting from adopting AI itself, it starts by sorting out the roles of employees, AI, and METABIRDS.

Employees bring domain knowledge and set priorities. AI is used as a tool that speeds up code generation, drafting, and research/summarization. METABIRDS handles design and technical decisions, code review, security, and production readiness, and joins the implementation itself where needed. Sorting out these three roles up front creates a state where “the company keeps the reins of development, and only the hard parts go to professionals.”

The same logic runs through how existing SaaS and systems get handled. Standard operations keep using SaaS (KEEP); systems get connected through AI or APIs (CONNECT); parts tied to a company’s specific competitive edge get built in-house (BUILD); and aging systems get replaced (REPLACE). Rather than pushing “stop using SaaS and build everything yourself,” it applies a neutral framework, judged operation by operation.

Why This Kind of Support Is Possible Now

“Building in-house with AI” is a new option in itself, but the setup that makes it safe to do doesn’t appear overnight. What lets METABIRDS offer this support is a stack of experience built up over time.

The company has developed and operated chatbots since 2012. From there, it expanded into external system integration, generative AI integration, retrieval-augmented generation (RAG) for knowledge search and document reference, autonomous AI agents, and, most recently, support for MCP (Model Context Protocol), a current integration standard.

What that accumulation means is that METABIRDS was designing and operating “systems that hold a conversation with AI” before AI coding tools existed at all. ChatGPT and Claude Code opened a door that lets non-engineers write code — but the layer that runs that code safely in production, secures it, and keeps it operating doesn’t get filled automatically just because AI tools keep improving. METABIRDS has a foothold in both layers — the prototyping layer AI is good at, and the production/security layer built up over years of operations — which is what makes it possible to offer support for “starting small without having to carry everything in-house.”

You Can Hand It Off Partway Through

Another feature is that this isn’t limited to greenfield development. Whether it’s a prototype built through vibe coding, an AI built in-house, or a system another company built, the starting point is the same: check the code, environment, licenses, and documentation, and assess whether a handover is feasible and how much rework it needs. The design starts from “what state is this in right now,” not “who built this.”

On security, METABIRDS operates under a structure based on ISO 27001:2022, the international ISMS security standard, and is used by companies where information-handling standards matter — including a listed company in the food industry and a major company in the gaming industry.

In Summary

AI coding tools have widened the range of who can build something. But they don’t automatically decide what should get built, or how much a company should keep in-house. In an environment where IT talent is structurally short and SaaS keeps multiplying on its own, someone needs to consciously own that judgment.

What “AI Adoption & In-House Development Support” offers isn’t the ability to write code — it’s a design for how development’s reins get shared between employees, AI, and outside expertise. What gets handed to AI, and where a professional needs to step in, changes depending on the situation. That’s why the service works in stages: an initial three months to sort out the current state, act on priority tasks, and agree on a path forward.

The starting point for this service is simple: tell us what’s going on right now.

AI Adoption & In-House Development Support by METABIRDS　https://aidev.metabirds.com/

Sources
  • METI (Japan’s Ministry of Economy, Trade and Industry), “Survey on IT Talent Supply and Demand” (published April 2019)
  • IPA (Information-technology Promotion Agency, Japan), “DX Trends 2024”
  • IPA (Information-technology Promotion Agency, Japan), “10 Major Threats to Information Security 2026” (published January 29, 2026)
  • Okta Japan, “Businesses at Work 2025”
  • Eltes Co., Ltd., survey on generative AI use in the workplace (published January 19, 2026)
  • Gartner Japan, domestic end-user survey on shadow AI (published June 18, 2026)
  • Vercel, official security bulletin (published April 19, 2026)
  • ShiftB, “The Limits and Pitfalls of Vibe Coding” and “7 Vibe Coding Failure Patterns and How to Prevent Them” (in-house survey of 142 students, published March–April 2026)
  • METABIRDS Co., Ltd., official site for “AI Adoption & In-House Development Support” (https://aidev.metabirds.com/)