AIのオンボーディング
本ページでは、GitHub CopilotというAIをプロジェクトに迎え入れることやそのサポート(オンボーディング)の重要性、必要性を解説します。
なお、本ページおよび配下のページで記載する内容はGitHub CopilotというよりAIを活用した開発の基本的なポイントのため、「AI」という言葉で説明することが多くなっています。
AIへの期待値とギャップ
生成AIを使うとさまざまな質問に答えてくれたり、すぐにでも使えそうなコンテンツを生成してくれるため、実際の業務(プロジェクト)に導入するとすぐに効果的な結果を生み出せると期待値が大きくなりがちです。
しかし、実際に使ってみると以下のようなギャップを生むことがあります。
- プロジェクトのルールに沿ったコードを生成してくれない
- 例: コーディング規約に沿ったコードではない、既存のコードと書き方がまったく異なるコードを生成する
- プロジェクトの構成を無視した回答や提案をしてくる
- 例: 既存のAPIや共通APIを無視して新しいAPIの実装を提案してくる
- 世の中に情報の少ないライブラリなどの使い方を誤る
- 例: 存在しないAPIを使うように提案してくる
結果としてAIとコミュニケーションする時間がムダに思えたり、手直しが増えたりするようなネガティブな印象になったり、AIに失望することもあるでしょう。
生成AIの本質と前提
ここで、生成AIの本質と前提を押さえておきましょう。
生成AIは「コンテンツの続きをもっともらしく生成する」というのが本質的な動きです。また「もっともらしく」というのは、AIが学習している内容や与えられた情報から導出されるものになります。
たとえば製造工程を対象とすると、AIは以下の内容を学習済みなことが多いでしょう。
- 一般的なプログラミングの知識
- 一般的なプログラミング言語やフレームワーク、ライブラリの知識
その回答内容も確率的で、同じ質問をしても異なる答えが返ってくることもあります。
一方でプロジェクトの構成や固有のルール、実現したい機能や既存仕様などについては知識を持ちません。学習していないライブラリなどの知識も持ちません。
AIがプロジェクトの構造などを解析して自動で認識し、適切な回答を生成することを期待するかもしれませんが、うまくいかないことが多いでしょう。
ここを補完しないままに抽象的な指示だけ与えてしまうと、AIが今持っている知識や情報からもっともらしくコンテンツを生成するため、「期待した結果にならなかった」というギャップを生みやすくなってしまいます。
またAIが知らないことをもっともらしく回答してくる現象は「ハルシネーション(幻覚)」と呼ばれており、AIが提案してくる内容は人が責任をもって確認する必要があります。
オンボーディングドキュメントの整備
AIが生成する内容は確率的ですが、プロジェクトの前提や共通知識をAIに伝えることで、より期待値に近い回答を生成するように調整できます。
つまり、プロジェクトではAIがプロジェクトで期待する成果を出せるようサポートすることが必要です。
これが本ページの主題である、AIのオンボーディングです。
AIのオンボーディングに向けてドキュメントの整備などが必要ですが、どのようなドキュメントが必要なのか、そのポイントなどは以下を参照してください。
AIにも適切に情報を与えないと実力を発揮できません。
たとえ言語やフレームワークのエキスパートがプロジェクトに参画しても、プロジェクトの事情や共通知識などを知るまではなかなかパフォーマンスがあがらないのと同じです。
AIを新しくプロジェクトに参画したメンバーのように捉え、他のプロジェクトメンバーへ指示したり情報を与えたりするのと同じように考えてみましょう。
AIは情報の読み取りと成果物の生成が高速に行えるプロジェクトメンバーだと考えた方が、どのようにAIに指示すればよいのか考えやすくなるでしょう。
将来的な改善
AIを効果的に活用するためには、従来のドキュメントに加えてAIが理解しやすい形式の情報提供も重要になります。
本ページおよびオンボーディングで必要なドキュメントについて記載した各ページを読み進めると、「GitHub Copilot(AI)へ情報を与えるだけのため」に準備が必要だと思われるのではないでしょうか。
これは追加の作業に思えるでしょう。
本ガイドでは、AIのために用意するドキュメントはMarkdown形式で作成することを想定しています。
一方で記載される内容自体は、プロジェクトの方式設計書や実装ルールなどから形式や書き方が変わったものになるでしょう。
表現したい情報は本質的には人やAIを問わずよく似たものになるはずなので、理想的にはヒューマンリーダブルかつAIリーダブルな資料として整備することが望ましいと考えています。
ただし本ガイド記載時点では、プロジェクトにおける人が見る設計書などはOfficeドキュメントで書かれていることを想定しており、これを含めて一気に変更するのはプロジェクトによっては難しいでしょう。
また、本ガイドで対象としていない工程での成果物から見直す必要があるため、後からドキュメントの運用を変更することが困難な可能性もあります。
対象工程と開発プロセスで説明したように、本ガイドではまずはGitHub Copilotがもっとも成果を出せるであろう工程での浸透を目的としています。
各工程で作成するドキュメントも含めてAIフレンドリーとするよう見直すのは、開発全体をカバーするガイドを作成する時に実施することを考えています。
もっとも、先行してドキュメントをAIフレンドリーなものに変えていくことを止めるものでもありません。
本ガイドはAIを導入する各プロジェクトが一定の成果を出せることを狙ったものであるため、開発プロセスを変えていけるプロジェクトは最適な成果物構成を選んでください。
📄️ 指示のポイント
GitHub Copilotから質の高いコードを引き出すためには、的確な指示(プロンプト)が不可欠です。AIを優秀な開発パートナーとして活かすには、人が「適 切なコンテキスト」と「明確なゴール」を与えることが重要です。
📄️ インストラクションやプロンプトを共有する
GitHub Copilotへ指示する際は、実装したい機能の要件や仕様を明確に伝えること、つまりどのようなプロンプトを書くかが重要です。
🗃️ 整備しておくファイル
8項目