2026.05.28

Vibe coding の実務では、強いモデルを常時使うより、タスクごとに速い・安い・強いモデルを切り替える方が現実的になる。モデル選択をプロンプトではなくインフラ設計として扱う流れが強まっている。

社内ツールを agent に触らせると、MCP server の配置、認証、権限、監査がそのままセキュリティ設計になる。VBC でも MCP を「つなぐ」だけでなく「どこまで触らせるか」まで教える必要がある。

業務 agent は「作って終わり」ではなく、評価と改善ループを持つことで実運用に近づく。Bootcamp の卒業制作でも、業務知識をどう検証し続けるかを設計に入れるべき。

frontier model そのものだけでなく、モデルを選び、ルーティングし、フォールバックする層が事業化している。VBC でも「どのモデルか」より「どう選び、観測し、切り替えるか」が重要になる。

受講者作品では status カラムや論理削除が雑に増えがち。運用・監査・問い合わせ対応を考えるなら、状態ではなく事実を残す設計を早い段階で教える価値がある。

NotebookLM を「資料を入れて要約する箱」で終わらせず、出力設計と参照設計を教えると、調査・教材化・提案準備の品質が上がる。VBC の資料読解ワークにもそのまま使える。

AI で作業が速くなるほど、流暢だが前提がズレた成果物のリスクが増える。出力とレビューを分ける型は、個人のプロンプトから複数 agent の設計まで使える基本動作になる。

AI coding agent をブラックボックスで使うだけでは、失敗時に設計を直せない。loop と tool call の構造を自作で理解する教材は、VBC の上級カリキュラムに向いている。