バイブコーディングの成果物の質を上げるために必要なのは…

バイブコーディングの成果物の質を上げるために必要なのは…

元論文：Computer Science Achievement and Writing Skills Predict Vibe Coding Proficiency

自分でコードを書くのではなく、AIに対してやりたいことを伝えて、AIにコードを書いてもらう開発手法をバイブコーディングと言います。
このバイブコーディングのハードルが下がっているため、「これからはコーディングの知識は不要、仕様を話せればそれでいい」という意見もよく聞くようになりました。

今回の研究は、その意見が本当に正しいのかを検証したものになります。

研究の方法

今回の研究では、AIを使って自然言語でアプリを作る能力（vibe coding proficiency）に、ユーザーの「文章力」「コンピュータサイエンス（CS）の達成度」「一般的な認知能力」がどの程度関係しているのかを調査しています。

1. 文章力の測定

参加者は、大学で学ぶ技術の概念を非専門家向けに300〜450語、2〜3段落で説明する文章を書きました。

採点では、対象読者に伝わるか、段落の構成、文の明確さ、文同士のつながり、言語自体の質などが評価されています。論文では、この課題はAIにうまく命令するスキルを直接測るものではなく、技術的内容を相手に伝わる形で文章化できる能力の指標として扱われています。

2. CS達成度の測定

CS達成度は、SCS1の12項目短縮版で測定されています。
これは、特定のプログラミング言語に依存しない擬似コードをベースとしたテストで、定義に関する知識、コードの追跡（トレース）、コードの補完などができるかを評価します。

3. 一般認知能力の測定

一般認知能力はICAR16で評価されました。
言語ベースの推論や行列ベースの推論、文字列の操作、3D回転などを含む、比較的広い領域の認知機能（イメージとしてはIQに近い）を見るテストです。

4. バイブコーディングの課題

課題は、大きく以下の3つに分類されます。

• Replication Task：見本のアプリを、その挙動が同じになるように作り直す課題
• Feature Addition Task：見本アプリに、新しい機能を追加する課題
• Decontextualized Task：目的のアプリがどのような用途で使うのかがわからない状態で、機能を細かく説明しながらアプリを作る課題

5. 参加者

参加者は大学生100名で、入門レベルのCS科目を履修済みで生成AIを使ったプログラミングの経験があり、英語力も一定水準以上という条件が設けられています。

結果

1. Decontextualized Taskのスコアが最も低かった

特にDecontextualized Taskの成績が低く、参加者にとって非常に難しかったことがわかります。
例えば、あらかじめ予約アプリを作るとわかっていれば、「予約アプリを作って」と言えばAIがある程度配慮してくれると思われます。しかしこのような情報がなくなると、こちらから明確に指示をしないと機能が実装されなくなるため、他の2種類のタスクと比べて難しかったと考えられます。

2. CSの知識は、文章力以上に重要だった

各能力とバイブコーディングの成績との関連は、次のように報告されています。

• Writing skills（文章力）とバイブコーディング：r = 0.290, p = .003
• CS achievement（CS達成度）とバイブコーディング：r = 0.386, p < .001
• Cognitive ability（認知能力）とバイブコーディング：r = 0.352, p < .001

いずれの項目も、バイブコーディングの成績と弱い正の相関を示しました。
また、認知能力の影響を除いた場合（偏相関）は、以下のような結果となりました。

• CS達成度とバイブコーディング：r = 0.281, p = .005
• 文章力とバイブコーディング：r = 0.186, p = .066

つまり、一般的な認知能力とは別にコンピュータの基礎（CS）をよく理解していることは、バイブコーディングの上手さと結びついていたと考えられます。ただ、この分析では文章力とは相関がほとんどなく、検定結果でも有意差を確認できませんでした。
加えて、文章力とCS達成度を比較したとき、どちらの方がより寄与が大きいのかを検証した結果、寄与度はCS達成度の方が大きかったことも示されました。

これらの結果から、よいアプリを作るには「何をどんな順番で動かすか」「どんな条件で分けるか」「間違いが起きたときにどうするか」を考える力が必要であり、そうした力につながるCSの理解が、文章力以上に重要である可能性が示唆されました。
「これからはコーディングの知識は不要、仕様を話せればそれでいい」という考えを、覆すような結果が得られたといえます。

探索的データ分析：文章力・プロンプト品質・成績の関係

論文では、文章力が高い参加者ほどプロンプトの品質が高く、そのプロンプトの品質がバイブコーディングの成績と関連していたと述べられており、文章力とバイブコーディングの成績の関連のおよそ半分程度が、プロンプトの品質によって説明できる可能性があると示唆されています。

ただし、これは横断研究であり、因果を証明するものではありません。
それでも、少なくとも「読み手を想定し、必要な情報を伝える能力」が、AIとのやり取りで武器になりうる可能性は十分考えられます。

注意点

• データ分析などのバイブコーディングの課題に関しては検討されていません。
• 文章力の評価尺度は研究用に独自作成されたもので、成人の一般的な文章力を完全に反映できているとは言えません。
• 文章力やCS達成度が高いとバイブコーディングが上手くなるという因果関係が示されたわけではありません。

---

調剤薬局でバイブコーディングをするなら…

「色々な人がAntigravityやClaude Codeですごいアプリを作っているから、私も作ってみたい！」といってトライするのは、良いことだと思います。
ただ、作ったアプリを実際に業務に投入したいと考えているなら、色々と知っておくべきことがあります。

今回の研究では、バイブコーディングにおいて文章力とCS達成度の両方が成績と関連し、とくにCS達成度のほうがより強い予測因子だったと報告されています。
つまり、AIにそれらしく伝える能力だけでなく、条件分岐や状態の管理、例外処理のような構造を考える基礎力も重要であることが示唆されています。

よって、調剤薬局でバイブコーディングを活用するなら、具体的に何を解決したいのか、そのためにはどのような条件・機能が必要なのかを整理することが大切です。

「アプリを作って」だけでは不十分

例えば、「調剤薬局のスタッフ間で、新着情報や連絡事項を共有するためのアプリ」をバイブコーディングで作ることを考えてみましょう。これは一見、「連絡事項や情報を投稿できる」「スタッフが閲覧できる」の2点を満たしていれば良いと思われるかもしれませんが、実際は色々決めておくべきことがあります。

具体的には…

• 誰が投稿・閲覧できるようにするのか
  薬剤師に絞るのか、他のスタッフも含めるのか。
• 投稿内容（カテゴリ）を分類する必要があるのか
  「新着情報」「医薬品供給状況」「シフト変更」などに細分化するのか。
• 既読確認機能が必要か
  すべての投稿に標準搭載するのか、それとも投稿時に投稿者が設定できるようにするのか。さらに、一定時間後に再通知する必要があるのか。
• 過去のお知らせを検索する機能が必要か
  キーワード検索に絞るのか、カテゴリ検索もできるようにするのか。
• 個人情報や機密情報の投稿の扱いはどうするか
  そもそも、このような情報が投稿できる必要があるのかどうかから慎重に検討する。加えて…
  • 自由記述で患者さんの情報を書く形式だと、リスクが高い。
  • 厳格なアクセス制御やアクセスログの管理も必要になる。
  • アクセスできる端末も制限する必要がある。
    • その端末には二要素認証などを含む複数の安全対策が必要となる。

こうした条件を整理しないまま、AIに「調剤薬局のスタッフ間で、新着情報や連絡事項を共有するためのアプリを作って」と頼んだ場合、見た目はそれらしくても現場では使いにくいアプリになってしまうかもしれません。

なので、実際にAIに指示をする前に、アプリに求める条件を整理する必要があります。

どんなアプリを作りたいかではなく、何を解決したいのかを明確に

いきなりアプリの条件を考えるのではなく、アプリで本当に解決したい課題は何なのかを明確に定義することが重要です。
そこを明確にしてから、「課題の解決のためにどのような機能が必要か」「どんなトラブルが起こりうるか」「利便性より安全性を優先すべき部分はあるか」といった内容を順番に整理していくとよいでしょう。

例えば、先程の連絡アプリで解決したい課題が…

• 「こちらからのお知らせが十分周知されない」なら
  既読管理機能および未読者への通知機能が必要になるでしょう。
  一方で、「既読機能へのプレッシャー」を感じるスタッフもいるかもしれません。スタッフ全員で予め話し合って、この機能に関連するルールを決めておく必要があります。
• 「情報が多く、現在使っている掲示板では情報が埋もれる」なら
  掲示板形式にこだわるよりも、検索機能およびカテゴリ分けや固定表示ができる機能が必要になるでしょう。
  一方で、カテゴリの誤った分類や独自の略語の使用などがあると、思い通りに機能しません。カテゴリ分類の基準や使用できる略語などを、予め決めておく必要があります。
• 「スタッフのシフト変更関連の連絡が多く、管理が大変」なら
  スタッフ用のカレンダーアプリ（Googleカレンダーなど）との連携機能が必要になるでしょう。
  一方で、スタッフ個人所有の端末で閲覧できてしまうと、仕事とプライベートの境目が曖昧になるだけでなく、情報漏洩のリスクもあります。アクセスログの管理や端末の制限などの設定が必要です。

このようなことを考える必要があります。

「全部盛り」はリスク

そんな細かい事を考えなくても、「全部盛り」のアプリを作れば良いじゃないかと思われるかもしれません。しかし、アプリは作って終わりではありません。実際に業務に組み込むならば、責任を持って保守管理し続けなければならないのです。

例えば、先程の連絡アプリでカレンダーとの連携機能を実装した場合、定期的な権限の棚卸しや端末の管理、APIの仕様変更への対応、バックアップ…などが必要になります。
もちろん本当に必要なら、このような保守管理をすることを前提に実装するべきですが、必要性が薄いのに実装してしまうと保守管理が疎かになってしまい、セキュリティホール（脆弱性）になってしまうおそれがあります。

仮に調剤薬局内に情報システム部門があって、そこでずっと保守管理できるのであれば全部盛りでも良いですが、調剤薬局の現場においてバイブコーディングでアプリを開発する場合は、おそらく情報システム部門が存在しないことのほうが多いでしょうから、全部盛りのアプリの保守管理は手に余る状況になるでしょう。

また、別の研究 [1] では以下のようなことも示唆されています。

• 複雑な要件のアプリは、バイブコーディングだけでは難しい
• テストで動いても、実際の現場で思い通りに動くとは限らない

このような観点からも、アプリの機能は必要最小限に抑えたほうが良いと考えられます。

今回のまとめ

今回の研究では、バイブコーディングの成果物の質に関しては文章力とCS達成度の両方が関係していましたが、特にCS達成度の方が強い予測因子である可能性が示唆されました。

この示唆を踏まえると、実際にバイブコーディングでアプリ開発をするにあたっては、まずは自分たちがアプリを使って具体的に何を解決したいのか、そのためにはどのような条件・機能が必要なのかを整理する必要があると考えられます。

調剤薬局でバイブコーディングをする際も同様です。
何でもできる「全部盛り」のアプリは完成させるのが難しいだけでなく、保守管理が十分行き届かない状況に陥る可能性があり、セキュリティホールにもなり得ます。
ゆえに、現在の課題を定義し、どのような機能が必要なのかを特定し、生じうるトラブルや安全対策についても十分考慮したうえで、必要最小限の機能を備えたアプリの完成を目指すほうが良いでしょう。

---

参考文献

[1] Tran, H et al. (2026). Vibe Code Bench: Evaluating AI models on end-to-end web application development.