はじめに
GMOコネクトの平島です。
チームで Claude Code を使い始めてから、便利になったのと引き換えに困ったことが起きています。「誰かが作ったらしいSlack通知ツール」「似たような集計スクリプトが3本ある」「作った本人がいないと何もわからない」😇
この光景、2019年頃のRPA普及期にも見た気がします。あのときどう乗り越えたかを参考に、バイブコーディング時代のオーケストレーション設計を考えてみました。
先にまとめ
起きていること: バイブコーディングによる「影のAI開発」が拡大し、個人依存・重複・ブラックボックス化が進む
構造的な類似: RPA普及期（2018〜2020年）の「現場ロボット乱立」と同じパターン
必要な打ち手:
| レイヤー | 内容 | 最小構成 |
|---|---|---|
| カタログ | 何が存在するかを一覧化 | スプレッドシート1枚 |
| 所有者定義 | 誰がオーナーか・誰が触れるか | READMEに明記 |
| ライフサイクル | 棚卸し・引き継ぎ・廃止の手順 | 月1回の定例レビュー |
| テンプレート | 構造の共通化 | 共有リポジトリ |
バイブコーディングで起きていること: 3つの症状
症状1: 誰が作ったかわからない
Claude Code や Cursor でアプリを作るコストが下がったため、個人ツール・社内スクリプト・自動化ボットが急増します。問題は、それらが 個人のローカル・個人のGitHubリポジトリ・個人のSlack通知 に散らばることです。
「このスクリプト誰が持ってる？」という会話が発生したとき、Slackのログをさかのぼることになります。
症状2: 担当者がいないと止まる
バイブコーディングで生まれたツールの多くは、作った本人しかデプロイできない・直せない 状態になりがちです。AIが生成したコードは動いてはいますが、その構造を理解しているのは作った人だけ、というケースが頻繁に起きます。
担当者が異動・退職した際に「ツールが止まった」「ログインできない」「そもそも何をしていたかわからない」という事態になります。
症状3: 同じものを何度も作る
カタログが存在しないと、「似たようなものがすでにある」に気づけません。Slack通知を送るためのスクリプトが部署ごとに3本、データ集計ツールが4本、という重複が発生します。AIを使えばすぐ作れるので、「探す」より「作る」が速いというインセンティブもあります。
これ、RPAで見た光景だ
2018〜2020年頃のRPA普及期に同じことが起きています。
UiPath・WinActor・Blue Prism が注目を集め、「ノーコードで業務自動化できる」という触れ込みで現場への導入が加速しました。IT部門を通さずに各部門が独自にロボットを作り始め、短期間で組織全体のロボット数が爆発的に増えました。
| 問題 | RPA普及期 | バイブコーディング現在 |
|---|---|---|
| 作成者の属人化 | ロボット設計者がいないと直せない | コードの構造を理解しているのは作った本人だけ |
| 退職リスク | 担当者退職でロボットが止まる | 担当者異動でツールが誰も触れなくなる |
| 重複開発 | 同じ業務を自動化したロボットが複数存在 | 同じ機能のスクリプトが複数チームに散在 |
| ブラックボックス化 | ロボットの内部ロジックを誰も把握できない | AI生成コードの意図が引き継がれない |
| 統制の不在 | セキュリティ・権限管理が各ロボットでバラバラ | 認証情報・APIキーの管理がバラバラ |
構造が同じです。「個人でも簡単に作れる」「作るコストが劇的に下がった」という特性が、ガバナンスの整備より先に普及が進む状況を生み出しています。
RPAはどう乗り越えたか
RPA業界が出した答えは CoE（Center of Excellence） と オーケストレーター です。
CoEは社内のRPA推進・管理を担う横断組織です。各部門が勝手に作ったロボットを一元管理し、設計標準・セキュリティポリシー・ライフサイクル管理を定義しました。技術的には UiPath Orchestrator のようなプラットフォームがロボットの実行・監視・権限管理を担いました。
IT部門が全ロボットを作る体制に戻したわけではなく、現場が作ることは認めつつ、カタログ・所有者・ライフサイクルを整備した。現場の自由度を残しながら、見える化と引き継ぎ可能性を担保したのがミソです。
バイブコーディング時代も同じアプローチが使えます。
オーケストレーション設計の具体例
「重厚な仕組みを作る前に、最小構成で始める」が基本方針だと考えています。
Step 1: カタログを作る（スプレッドシートで十分）
まず「何が存在するか」を一覧化するだけで、重複開発と属人化の発見速度が上がるはずです。
管理項目の最小セット:
| 項目 | 内容 |
|---|---|
| 名前 | ツール・スクリプトの名称 |
| 用途 | 何をするものか（1行） |
| オーナー | 責任者（メインとバックアップ） |
| 場所 | リポジトリURL・保存場所 |
| 最終確認日 | 棚卸し用 |
| ステータス | 現役 / 休眠 / 廃止予定 |
スプレッドシートで始めて、件数が増えたら Notion や社内ポータルに移行すれば十分です。
Step 2: 所有者を明示する
バイブコーディングで作ったツールには、最低限以下をREADMEに書く運用が有効だと考えています。
## オーナー
- メイン: [名前]（Slack: @username）
- バックアップ: [名前]（Slack: @username）
## 概要
何をするツールか（3行以内）
## 動かし方
\`\`\`bash
# 最低限の起動コマンドだけ書く
\`\`\`
## 依存しているもの
- APIキー: [どこに保存されているか]
- 外部サービス: [何に繋いでいるか]
「AIが生成したコードだから自分も把握しきれていない」という状況は起こります。それでも 誰に聞けばいいか・何に依存しているか だけ書いておけば、引き継ぎコストは大きく下がるはずです。
Step 3: 定期棚卸しを仕組み化する
月1回・30分の定例棚卸しをカレンダーに入れておくとよいと思います。確認項目はシンプルに。
- カタログに載っていないツールが増えていないか
- ステータスが「現役」になっているが実際に使われているか
- オーナーが異動・退職していないか
RPA時代に報告されたパターンでは、棚卸しなしで放置した場合、半年後に「誰も触れないロボットが動き続けている」 という状態が多発しています。AIツールでも同じことが起きかねません。
Step 4: 共有テンプレートを用意する
繰り返し作られるパターンに対してテンプレートを用意すると、構造の属人化を防げます。
社内でよく作られるパターン例:
- Slack通知スクリプト
- スプレッドシート → BigQuery の定期取り込み
- API定期実行 + 結果通知
テンプレートがあると「AIに聞いて似たものを作る」が「テンプレートをコピーして必要な部分だけ変える」に変わります。これにより認証・ログ・エラー処理の設計が統一されることを期待しています。
設計上の注意点: 「管理しすぎ」でバイブコーディングの利点が消えるリスク
RPA時代の失敗パターンを参考にすると、以下の3点が陥りやすい落とし穴として挙げられます。
注意点1: 申請フローを重くしすぎると逆効果になる
「ツールを作る前に審査を通す」という仕組みを作ると、バイブコーディングの最大の利点である 「思いついたその日に動くものができる」 が消えます。
週1回の審査待ちが発生した時点で、開発者は審査を迂回する方法を探し始めることが予想されます。結果として「管理されていないツールが増える」という逆効果になりかねません。
提案: 作ること自体は自由にする。ただし作った後7日以内にカタログへの登録を義務にする。
注意点2: カタログの更新は仕組みで担保する必要がある
カタログを作っても、更新されなければ意味がありません。「更新してください」というリマインドを自動化しても、忙しい時期は無視されるケースが多いと考えられます。
提案: 棚卸し定例を四半期に1度、45分で実施する。全件確認ではなく「最終確認日が3ヶ月以上前のもの」だけ対象にする。
注意点3: バックアップオーナーが形骸化しやすい
バックアップオーナーを形式的に設定するだけでは不十分で、そのバックアップが実際に動かせるかを確認する 機会がなければ意味がありません。
提案: 四半期に1度、バックアップオーナーがツールを実際に起動・動作確認する。このログをREADMEに残す。
まとめ
- バイブコーディングはRPA普及期と同じ属人化・重複・ブラックボックス化のリスクをはらんでいる
- 最小の打ち手は「カタログ・所有者・棚卸し・テンプレート」の4点。スプレッドシート1枚から始められます
- 重厚な申請フローより「後から記録する」設計のほうが機能しやすいと考えています
- まだ運用実績はなく提案段階ですが、RPAの轍は踏みたくない
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。