バイブコーディングで社内業務ツールを作る手順と引き継ぎ情報の残し方
参照したAIgram
目次
概要
生成AIに指示を出しながらツールを作る「バイブコーディング」で、社内の困りごとを自分たちで解決したい、と考えている方は多いと思います。実際にそれをサービスとして提供している例もあります。大塚商会の「業務プロセス自動化 AIサービス」は、まずユーザーへのヒアリング/コンサルティングで自動化対象の業務を定め、プロトタイプを早期に示しながら対話的に改善を重ねることで、要件のミスマッチを抑えつつ従来型の受託開発より開発期間を短縮してシステムを納品します 大塚商会AIサービスで定型業務を短期開発。
一方で、現場で作られるツールの多くはバージョン管理がされず、テストも十分ではありません。プロンプトが残っていなかったり、AIモデルが更新されたりすると同じコードを再現できず、業務要件や判断理由という意図が失われると、修正も再設計もできなくなります 生成AIバイブコーディングとIT部門の統制。この状態を避けるための道具立ては、すでに他の事例に見えています。GitHub Copilotは開発者の指示のもとでテストの実施やその結果の検証といった反復的なタスクに対応でき、富士通ではMicrosoft Dev Boxとの活用で開発者の作業負荷を20%削減しました 富士通、Dev BoxとGitHub Copilotで開発負荷20%削減。デンソー工機部は案件・担当者・コスト・取引先などを紐づけてDataverseに格納し、ベテランの引退時にはTeamsの録画データを構造化して同じ基盤に入れることで有益な財産になるとしています デンソー工機部、Dynamics 365で工数20%削減へ。
ツールを作る手順は、対象業務を定型作業に絞る、扱うデータを線引きする、要件と判断理由を資料にする、単純な形から対話で作る、テストとレビューを入れる、プロンプトと使用モデルを残す、引き継ぎ情報を蓄積する、運用コストと復旧手段を見積もる、の順で整理できます。
対象業務を転記・集計などの定型作業に限定する
大塚商会のサービスでは、開発に入る前に、ユーザーへのヒアリング/コンサルティングによって自動化対象の業務を定めます。システム化の対象は主に、これまで人手に頼ってきた転記・集計・帳票作成などの定型業務です。「Microsoft 365」や「kintone」などの既存システムとのAPI連携処理も実装します 。
対象を絞ることには理由があります。バイブコーディングは小規模なツール開発を容易にした一方で、大規模なシステム開発には依然として不向きであり、設計や仕様を詰める能力がなければすぐに破綻するとされています 。作れる範囲を最初に決めておくほうが、後から作り直す量は少なくなります。
- 毎回同じ手順で、判断がほとんど入らない作業を候補にする
- 転記、集計、帳票作成のように、入力と出力がはっきりしている作業から選ぶ
- 業務全体をまとめて置き換えようとせず、一つの作業単位に区切る
扱ってよいデータの範囲を作る前に線引きする
作り始める前に、そのツールがどのデータに触れるのかを決めます。IT部門の対応としては、個人の業務効率化や読み取り専用のツールは許可する一方、書き込み系の処理や顧客データを扱う処理、基幹システムとの連携は原則禁止とするなどの線引きが必要とされています 。
もう一つ確認したいのが、生成AIへ何を入力するかです。履歴書や問い合わせ内容には個人情報や機密情報が含まれ、これらを生成AIに入力した場合、外部サービスへのデータ送信が発生する可能性があります。必要なのは、どの処理にAIが使われるのか、外部送信があるのか、データが保存されるのかという処理フローの明示です 。
読み取りだけで済むのか、書き込みが必要なのか。個人情報を入力するのか。この2点を作る前に決めておくと、後から作り直す範囲が小さくなります。
要件と判断理由を資料の形式で記録する
対象とデータの範囲が決まったら、要件を資料として残します。ここで参考になるのが、TISIとアットストリームコンサルティングの取り組みです。システム企画工程の資料作成を支援するAIエージェントを開発し、次の6種類の資料の下書きを、経験者のノウハウを学習した生成AIが作成します TISI、AIエージェントでコンサル工数最大7割減。
- ヒアリング内容の要約
- 業務・システム課題の分析
- 課題・要望整理
- As-Is/To-Be業務整理
- 業務フロー作成
- システム要求事項整理
2025年度に実施した複数の実案件に適用し、論点整理や業務フロー作成などの工数を従来比で3〜7割削減しました。資料のフォーマットを標準化することで論点・前提・結論を明確に整理しやすくなり、関係者間の認識統一と合意形成までのリードタイム短縮に寄与しています
。
この作業は、後々の引き継ぎに直結します。バイブコーディングで生まれる負債は、意図そのものが消失している状態です。コードが動いていても、背景にある業務要件や判断理由が説明できなければ、修正も再設計もできません 。「なぜこの処理があるのか」を書いておくことが、そのまま引き継ぎ情報になります。
単純な形から作り対話で修正を重ねる
実際に作る段階では、いきなり完成形を目指さないほうが進みます。3D CADの例では、生成AI（Gemini）に「FreeCADで幅80mm、奥行き50mm、高さ30mmの直方体を作成するPythonコードを作成してください」と指示し、出力されたコードをFreeCADに貼り付けて実行すれば、指定した寸法の3Dモデルを作成できます Gemini・MCPで3D CAD作成を支援。
ただし、AIが生成したスクリプトがそのまま正しく動作するとは限りません。まずは単純な形状から試し、エラーが発生した場合には表示されたエラーメッセージを生成AIに伝えながらコードを修正していく進め方が示されています 。
大塚商会も、プロトタイプを早期に示しながら対話的に改善を重ねることで、要件のミスマッチを抑えています 。早い段階で実物を見せて、違うところを指摘してもらう。この往復が、要件のずれを小さくします。
利用者が操作できる入力画面まで作成する
自分だけが使うなら、コードを直接書き換えても困りません。しかし社内の他の人に使ってもらうなら、操作できる画面が必要になります。生成AIを利用すると、3Dモデルを作成するコードだけでなく、入力ボックスや選択メニュー、チェックボックス、ボタンなどで操作するGUI付きスクリプトも生成できます。利用者はコードの中身を理解していなくても、必要な寸法を入力するだけでモデルを作成できます 。
この仕組みは、社内で使用する簡易的な設計ツールをはじめ、標準部品や治具、ケース、ブラケットなどを自動作成する用途にも活用できるとされています 。入力欄と実行ボタンがあるだけで、使える人の範囲は大きく変わります。
テストと人によるレビューを工程に組み込む
動いたように見えることと、正しく動くことは別です。テスト自体はAIに手伝ってもらえます。GitHub Copilotは開発者の指示のもと、テストの実施やその結果の検証といった反復的なタスクに対応し、編集案の提示やエラーのヘルプなどの支援も行います。富士通ではMicrosoft Dev Boxとの活用により開発者の作業負荷を20%削減し、2025年には375,000時間の節約を見込んでいます 。
同時に、人の目も必要です。認証処理の簡略化やエラーハンドリングの無効化、機密情報のハードコードといったAI生成の危険なコードは、一見すると正しく動くため、レビューをしなければ見逃されます 。3D CADでも、複雑形状においては設計者が寸法、形状、設計意図を検証する必要があるとされています 。
- テストの実施と結果の検証は、AIへの指示で反復的に回す
- 認証、エラー処理、機密情報の扱いは、人が必ず確認する
- 出力が業務上正しいかどうかは、その業務を知る人が判断する
今後は「コードをレビューできる人材」の価値が高まり、設計の妥当性やセキュリティ、データ整合性を判断できる能力が求められるとされています 。
プロンプトと使用モデルを生成履歴ごと保存する
生成AIに依存した開発では、プロンプトが実質的な仕様書になります。しかしそのプロンプトが残されていなければ、同じコードを再現できません。さらに、利用するAIモデルの更新によって、同じプロンプトであっても異なるコードが生成される可能性があります 。
そのため、管理すべき対象はコードと仕様書だけでは足りません。プロンプトと生成履歴、利用したモデルといった生成プロセスにまで広がります。どのような指示でどのAIを使い、いつ生成されたのかを追跡できなければ、再現性も説明責任も確保できないとされています
。
- ツールを生成したときのプロンプトを、コードと同じ場所に保存する
- 使用したAIサービス名とモデル名、生成した日付を記録する
- 修正のたびに、追加で出した指示も追記していく
引き継ぎ情報を構造化データとして蓄積する
作った人がいなくなった後も直せる状態にするには、情報を後から探せる形で貯めることになります。デンソー工機部は、案件、担当者、コスト、取引先などをすべて紐づけてマイクロソフトのクラウドデータベースサービスDataverseに格納しています。データが構造化されているため、CopilotやAIエージェントが活用しやすく、精度の高い回答が返ってくるとしています 。
同部の「熟練設計者の暗黙知を組織知化」は、過去トラブルを含むリスク情報をもとにAIが懸念と対策を推奨するもので、若手設計者の品質向上を図る取り組みです。ベテランの引退時には、Teamsの録画機能で「武勇伝」を語ってもらい、その録画データを構造化してDataverseに入れることで有益な財産になるとしています
。同部は、マイクロソフト製品を活用したAI DXにより作業工数を約20%削減、年間約8万時間の創出を見込んでいます。
社内ツールでも考え方は同じです。作成者と責任者、対象業務、扱うデータ、過去に起きた不具合とその対処を、決まった項目で書き残しておくと、次の担当者が読める情報になります。
運用コストと停止時の復旧手段を見積もる
バイブコーディングはコスト削減の手段として語られる傾向がありますが、実際にはコスト構造が変化しているだけだとされています。開発コストは下がる一方で運用コストは増加し、属人化したツールの引き継ぎやバグ修正、仕様変更のたびに発生する再生成作業に加え、AI利用料が積み上がります 。
- 実行のたびにAPIコールが発生する設計では、利用量の増加に比例してコストが増加する
- 外部APIの制限、モデルの変更、料金体系の変更により、ある日突然ツールが動かなくなる可能性がある
- 誰も仕様を理解していなければ復旧は極めて困難であり、BCPの観点からも無視できないリスクとされる
止まったときにどうするかを、作った時点で決めておきます。手作業に戻す手順が残っているか、誰が直すのか。ここまで書いておいて、はじめてツールとして渡せる状態になります 。
結論
大塚商会は、自社内のシステム開発で蓄積したバイブコーディングのノウハウを顧客のシステム開発支援に適用し、対象業務の特定から対話的な改善、導入後の運用支援までを一続きの手順として提供しています
。社内で作る場合も、この一続きの形をなぞることになります。
手順としてまとめると、次のようになります。
- 対象業務を転記・集計・帳票作成などの定型作業に絞り、扱ってよいデータを先に線引きする
- 要件と判断理由を資料として残し、単純な形から対話で修正を重ねて作る
- 利用者が操作できる入力画面まで用意し、テストと人によるレビューを工程に入れる
- プロンプトと使用モデルを生成履歴ごと保存し、引き継ぎ情報を決まった項目で蓄積する
- 運用コストと、停止したときの復旧手段を見積もっておく
最低限の開発ルールとして、バージョン管理やテスト環境の分離、作成者と責任者の明確化といった基本的な統制は外せないとされています。そして重要なのは、この技術を使うかどうかではなく、統制できる状態で使えているかどうかです 。
大塚商会は今後、業種別テンプレートを拡充し、ユーザー自身がバイブコーディングを実践してシステムを内製化する取り組みを支援するメニューを強化するとしています 。自分たちで作る場面は、これから増えていきます。
難しい技術ではなく、対象業務を絞り、要件と判断理由を書き、プロンプトと使用モデルを残す。この積み重ねが、止まったときに直せるツールと、そうでないツールを分けます。