能動的行為と受動的行為を定義する

能動的な行為とは、自らの内発的なモチベーションのもと、"こうしたい"というような目的意識を持って行う行為だと考えた。

反対に受動的な行為は、意図・意思の欠如した行為のことを指す。

例えば、テレビやYouTubeを見るときには単に時間を過ごすためや、習慣的に視聴することが多い。 このような行為は、自動的だし、意識的な決定や選択をしているというよりも単純に退屈や暇つぶしを行っているだけになっている。

ただ、動画を見るという行為であっても、"これを調べたい"、"これどうなっているんだろう"というような内的な興味や好奇心から行うのであれば能動的な行為だと言える。

僕は子どもが没頭することは大事だと思っている。子どもが夢中になって取り組めることがあるなら支援したい。没頭できる環境を作ってあげたい。 では夢中ならなんでも良いのかというと、そうではない。その基準が能動的か受動的かということだ。受動的な行為に没頭することは推奨しない。

なぜ受動的行為を推奨しないのか

受動的行為の代表格は、例に上げたようにテレビやYouTubeを見ることだと思う。

僕の子どもはちょうど一歳を過ぎたくらいで、まだ動画を見たいと騒いだりはしない。 しかし、周りの子育て中の親が子どもにタブレットを渡して動画を見せているのを見たことはある。 子どもがずーーーっと動画を見る。動画が止まると泣き叫ぶ。動画が再生されると静かになる。これは中毒である。

こうした様子を見るとなんとも言えない気持ちになる。 大人の自分もダラダラとYouTubeを見たりすることに罪悪感を感じているからである。

自分が罪悪感を感じるような行為を推奨できるだろうか。いや、なんとか一緒になくしていきたいものである。

そんな理由で受動的な行為を推奨しないことにした。道連れみたいなものだ。

基準を決めたら楽になる

最近何事も基準を決めておけばその後判断が楽だなぁと思うことが多いので、これも一つの基準として決めてみた。 奥さんとも話し合って決めたので、今後の子育てでこの基準をベースに意思決定していくことになるだろう。 基準があると、判断の軸が明確になるので、判断が楽になる。

最後に、この軸自体は将来ずっと守り通すというものではないと考えている。今時点ではこう決めた、というだけである。 未来は変わるし、子どもも変わる。変わったときにまた考え直せば良い。

ChatGPT に学習させる方法について

ChatGPT では内部で GPT という言語モデルを使っています。

こうした言語モデルに新しく情報を学習させる方法は大きく分けて３つあります。

1. 学習段階から自社データを学習データに入れておく方法
2. 学習済みのモデルに自社データを入れてファインチューニングする方法
3. プロンプトで学習させる方法

1 の場合、GPT のモデルは OpenAI が作成しているものなので、学習段階から明示的に自分が追加で学習させたい内容を盛り込むことはできません。このように事前に学習させたモデルのことを事前学習済みモデルと呼び、ChatGPT ではこのモデルをもとに、様々な自然言語タスクに応用することができています。 2 のように事前学習済みモデルに追加で学習させることをファインチューニングと呼び、自分たち独自のデータを追加で学習させる方法として最も一般的だと思います。 しかし、ChatGPT では現在ファインチューニングをサポートしていません。

したがって 3 のプロンプトで学習させる方法が ChatGPT においては最も一般的な学習方法と言えるでしょう。

プロンプトとは

プロンプトとは、ChatGPT に与える入力情報のことです。プロンプトには、回答に必要な情報を適切に与える必要があります。以下のような情報が含まれることが多いでしょう。

• 質問文や要求事項の文言
• 質問文や要求事項の文脈となる情報（例：商品やサービスの名前、地名、期間、数量など）
• 回答に必要な情報の整形方法（例：データのフォーマット変換、要約、加工など）
• 回答に必要な情報の出力方法（例：テキスト、音声、画像、動画など）

プロンプトエンジニアリングという言葉もありますが、プロンプトに与える情報の考え方は、ChatGPT の性能に大きく影響するため、非常に重要な要素です。社内情報やブログなどの情報を、質問や要求事項の文脈となる情報としてプロンプトに渡すことで、ChatGPT はそれをもとに回答を生成してくれます。 学習させるという単語を使っているので、ChatGPT はプロンプトに与える情報を学習しているように見えますが、実際にはプロンプトに与える情報をもとに、回答を生成させているだけです。

# プロンプトの例
# 質問文
〇〇プロジェクトの中で決めた〇〇という仕様ですが、なぜこのような仕様になってましたっけ？
# 質問文の文脈となる情報
{ここに社内の情報を記述する}
# 出力

上記のような質問を ChatGPT に投げれば、ChatGPT は社内の情報をもとに回答を生成してくれるはずです。

プロンプトの制約

では学習させたい全ての情報をプロンプト内に記述することができるのでしょうか。実はそうではありません。

ここでトークンについての理解が必要になります。トークンとは自然言語のテキストデータを分割した最小単位のことを指しており、プロンプトはトークンを並べた文字列として表現されます。プロンプトに渡せる質問文やそれに関連する情報は全てトークンとして処理されるわけです。

ChatGPT では一度に渡せるトークン数に上限があり、GPT-3.5 では最大 4096 トークン、GPT-4.0 では最大 8192 トークンとなっています。上限を超えるとエラーが発生します。 日本語は大体１文字で１トークンと計算されるため、だいたい 4000 文字程度しか渡すことができません。

この最大トークン制約があるため、単純にプロンプトに全ての情報を記述することはできません。プロンプトに与える情報を適切に整理し、必要最低限の情報をプロンプトに渡すことが重要です。

この上限は、ChatGPT が生成する回答の長さに制限があるためです。この上限を超えると、ChatGPT は回答を生成することができないため、エラーが発生します。

少し余談ですが、ChatGPT では会話の履歴を保持しているように思えますが実はそうではありません。 毎回の質問ごとに過去の会話履歴もプロンプトに渡すことで、会話の文脈を加味して返答しているだけなのです。 会話が長くなればいずれ最大トークン数を越えてしまうため、過去の会話を削ぎ落としていくようです。 したがって会話の履歴が長くなればなるほど、ChatGPT は始めの方の会話の文脈を考慮できなくなっていきます。

このように一度に渡せる情報量に上限がある ChatGPT に対して、どのようにすれば大規模な情報を学習させることができるのでしょうか。 いくつか手法はあるようですが、今回はプロンプトに渡す前段にベクトルベースの文章検索を挟む方法を紹介します。

文章ベクトルを使った検索方法

OpenAI にはEmbeddings API が存在します。 Embeddings では事前学習されたモデルを利用して、単語や文章のベクトル表現を取得することができます。

以下は Amazon のレビュー文章のベクトル表現を２次元にプロットしたものです。プロットの点の色は、レビューの評価を表しています。同じ色の点が近くに集まっていることがわかりますが、これは悪い評価のレビューや良い評価のレビュー文章は近い場所にプロットされていることを示しています。 このことから文章の類似性をベクトル空間上の距離で表現することができることがわかります。

引用元：https://platform.openai.com/docs/guides/embeddings/use-cases

具体的な手順

Embeddings を使って文章を検索する場合、以下のような手順で行うことができます。

1. 検索対象となる社内情報やブログ記事など、全ての文章をベクトル化する
2. ベクトル化した文章を永続情報として保存する
3. 質問文をベクトル化する
4. ベクトル化した質問文と保存したベクトル化した文章を比較し、質問文と類似度の高い文章を検索し、取得する

引用元：https://cloud.google.com/vertex-ai/docs/matching-engine/overview

質問文と文章の類似度は最近傍法によって計算されるのが一般的なようです。

こうして取得した文章をプロンプトに渡すことで、ChatGPT は検索された文章の文脈を考慮した回答を生成することができます。

# プロンプトの例
# 質問文
〇〇プロジェクトの中で決めた〇〇という仕様ですが、なぜこのような仕様になってましたっけ？
# 質問文の文脈となる情報
{検索して取得された、質問と類似性の高い文章をここに埋め込む}
# 出力

このプロンプトに渡す前に検索を行うという行為は、短期記憶と長期記憶という概念で考えるとイメージしやすいと思います。 長期記憶である文章ベクトル空間から関連する情報を抽出し、短期記憶であるプロンプトに渡すことで、ChatGPT はより正確な回答を生成することができます。

まとめ

今回は ChatGPT に情報を学習させることについて説明しました。 現在では一度に渡せる情報量に限りがあるため、利用者自身が渡す情報を工夫する必要があります。 こうした制限は徐々に緩和されていくでしょうし、あるいは今回紹介したような文章ベクトルを使う方法も今後はツール内に内包され、透過的に利用できるようになると思います。

しかし内部でどのように情報が処理されているかを理解しておけば、今後の活用イメージを広げることことができると思います。

先日社内のプロダクトマネージャーの方と話をしていて、プロダクトの価値について説明してもらったことがとてもわかりやすかったのでその内容をまとめておく。

限定的価値

限定的価値とはプロダクトが扱うコンテンツ・機能がそのプロダクトにしか存在しないという価値を指します。 そのコンテンツ・機能が他の場所では得られない限定的なものなので、そのプロダクトを使う理由になります。

例えば Netflix のオリジナルコンテンツも限定的価値の 1 つです。ストレンジャー・シングスやハウス・オブ・カードは Netflix オリジナルのコンテンツであり、他のストリーミングサービスでは視聴できません。仮に Netflix の料金が高く、UI/UX が使いにくかったとしても、これらのコンテンツを視聴したいなら Netflix を使わざるを得ません。

以前アーティストのファン向けサイトを運営している方がこんなことを言っていました。 「どれだけサイトへのアクセスに時間がかかろうが、サイト内の導線が不親切だろうが、ユーザはこのプロダクトを使う。なぜならグッズやチケットはこのプロダクトからしか買えないから。UI/UXは必要ないんだよね。」

上記は極端な意見ですが、本質を捉えていると思います。ユーザはプロダクトが扱っているコンテンツ・機能が他の場所では得られないということを知っているので、どれだけ体験が悪くても使います。これが限定的価値が最も強い価値といえる理由です。

しかし限定的価値には欠点があります。限定的なものにユーザが惹かれなければ、ただターゲットが狭いニーズに答えるだけのものになります。誰も欲しくないものを限定コンテンツとして提供しても使う理由になりません。 限定的価値は提供する機能・コンテンツを見誤ると最も弱い価値とも言えるので注意が必要です。

合理的価値

合理的価値とは、同じような機能・コンテンツを持つ競合プロダクトに比べて、より安く、より多くの価値を提供することで、ユーザ にとって合理的で魅力的な価値を提供することを指します。

Spotify のプレミアム会員を例にして考えてみましょう。Spotify で配信されている楽曲数は他の音楽ストリーミングサービスよりも豊富です。ユーザは同じ金額を払うとしても Spotify に払ったほうがより多くのコンテンツを楽しめることができるので、Spotify の方が得です。これが合理的価値です。

合理的価値は、価格が安いかどうかだけでは決まりません。価格の他にプロダクトの品質、機能、顧客サポート、信頼性など、多様な側面に基づいて決定されます。ユーザは自分が支払う金額・コストに見合った価値を得ることができるかを判断し、利用するかを決めます。

「支払う金額・コストに対して見合った、もしくはそれ以上の価値を提供できているか」が重要なので、必ずしも安くすればよいわけではありません。コスパが良いかどうかですね。

体験的価値

体験的価値は、そのプロダクトを使ったときに感じる楽しさや快適さ、高い満足感を提供する価値を指します。 限定・合理的価値が他と比べて同じである場合、最後はその体験が素晴らしいものかどうかでどのプロダクトを使うかが決まります。

UI/UX の使いやすさ、洗練さやプロダクトのレスポンスの早さなどは体験的な価値と言えます。動画ストリーミングサービスの場合、 同じ動画を視聴するとき動画のロードが早く、高画質で視聴できるサービスを選ぶはずです。 しかしそもそも視聴したいコンテンツがそのプロダクトに存在しなければどれだけ体験が良くてもそのプロダクトを選ばないでしょう。 こうした理由から限定や合理的価値より、体験的価値は弱いと考えています。

デザイナーやエンジニアは持っている専門性から、体験的価値を重視しやすい傾向があります。 しかし体験的価値はプロダクト価値の中でも最も弱い分類の価値であるということを忘れないようにしましょう。こだわることは大変良いことですがね。自戒を込めて。

プロダクトマネージャーは 3 つの価値をどう考えるべきか

説明してきたそれぞれの価値の強さを根拠にすると、プロダクトを作る際は限定的価値、合理的価値、体験的価値の順に機能・コンテンツを考えていくことが良いでしょう。 ただしプロダクトの状況や目的によってどの価値を磨いていくのかを変化させていく必要があります。

Netflix も始めはオンラインで動画がすぐ視聴できるところに限定的価値がありました。しかし競合プロダクトが出現し、オンラインで動画を視聴することが当たり前になってくると、オンライン視聴自体は限定的価値とみなされなくなってきます。

そこで視聴可能なコンテンツ数を増やすことで、合理的価値を他プロダクトより高めたり、高画質化で視聴体験を良くすることで体験的価値で競い始めます。そこでも差が出なくなってきたタイミングで、今度は各プロダクトが限定コンテンツを自社で作成し始めました。再度、限定的価値を作り出そうという動きです。

このようにプロダクトに必要な価値は、世の中や競合の動きによって常に変化します。そのため今のプロダクトが何の価値を持っているかを常に考え、磨いていく必要があります。

価値の重複

限定的価値、合理的価値、体験的価値は基本的に独立した概念ですが、重複する場合もあります。 例えば限定的価値を持つプロダクトはその希少性が高いため、それ自体が体験的価値や合理的価値につながることがあるでしょう。

そのため、プロダクトマネージャーは、3 つの価値を単独で考慮するだけでなく、相互に関連することも考慮しなければいけません。

まとめ

今回プロダクトの価値について考えてみましたが、これらを整理し理解したといって良いプロダクトが作れるわけではありません。 また3つ以外にも価値は当然存在します。(たとえば社会的価値など)

しかしプロダクトの機能開発を進める際、大雑把でも「今回はプロダクトのどの価値を作る目的なのか？」をメンバーですり合わせておくだけで、その後のコミュニケーションが円滑になると感じました。

限定的価値を作る目的なら、その機能が本当に価値を生むのかを検証する必要があるため、捨てても良い前提で開発を進めるといった選択肢を取ることができるかもしれません。 また体験的価値を作る目的なら、徹底して UI/UX やパフォーマンスにこだわりを持って開発する必要があるでしょう。

プロダクトの価値についての解像度があがれば、チームをどのモードに切り替えるべきかを判断する材料の一つとして役に立つはずです。

今回はこのコストがどういったロジックをもとに算出されているかを調べました。

EXPLAIN 実行計画を表示するコマンド

サンプルとして以下の EXPLAIN コマンドを実行します。

$ explain select * from users
    join user_basic_informations on users.id = user_basic_informations.user_id;

# 実行計画
Hash Join  (cost=4.55..28.62 rows=69 width=274)
  Hash Cond: ((users.id)::text = (user_basic_informations.user_id)::text)
  ->  Seq Scan on users  (cost=0.00..22.17 rows=717 width=110)
  ->  Hash  (cost=3.69..3.69 rows=69 width=164)
        ->  Seq Scan on user_basic_informations  (cost=0.00..3.69 rows=69 width=164)

実行計画では処理する単位のことを「ノード」と呼びます。上記の例では、Hash Join と Seq Scan などがノードです。

各項目の説明

各ノードには、cost, rows, width がそれぞれ表示されます。 以下の実行結果の一つを使って、それぞれの項目が何を表しているか説明します。

Seq Scan on users  (cost=0.00..22.17 rows=717 width=110)

• cost: ノードで処理するクエリのコスト
• rows: ノードが返却する行数
• width: ノードが返却する１行あたりの平均的な行の長さ

このうちクエリのコストを判断するのに最も重要なのは costです。(名前の通りですが) cost を算出する際に、rows, width も計算式内で考慮されているためです。

cost=N.NN..M.MM

cost はN.NN..M.MMのように表示されます。これはそれぞれ始動コストと総コストを表します。

N.NNの部分は始動コストと呼ばれ、１件目のデータを返却できるまでにかかるコストを表します。

M.MMの部分は総コストと呼ばれます。総コストは全てのデータを返却するまでにかかるコストを表します。

cost=0.00..22.17の場合、始動コストは 0 で、総コストは 22.17 です。

シーケンシャルスキャンでは、始動コストは 0 になります。シーケンシャルスキャンはテーブルの先頭から順番にデータを読み込むため、始動コストはかかりません。 インデックススキャンの場合は先に Index を読み込み、その後にテーブルからデータを読み込むため、始動コストは 0 になりません。 また Hash Join や Sort では、データを返却する前にデータをソートしたり、ハッシュテーブルを作成する必要があるため、始動コストが他に比べ大きくなる傾向があります。

始動コストはあくまで１件目のデータを返却できるまでにかかるコストです。始動コストが大きいクエリでも、総コストが小さければ実行時間は短くなります。

したがって、クエリの負荷を判断する上で重要なのは総コストです。実行計画を見て、そのクエリがどれくらいコストがかかるクエリかを判断するためには、総コストをチェックすると良いでしょう。

どのようにコストを見積もっているのか

ディスクからデータを読み出し、返却できるまでにかかるコストが総コストと述べましたが、クエリを処理する際 PostgreSQL 内では複数の処理ステップが存在し、それぞれにコストがかかります。 例えば、ディスクからデータを読み取る処理コスト、データを CPU 上で処理するコスト、WHERE 句といった operator を処理するコストなどです。

これらの処理はそれぞれ必要なコストが異なるため、各処理ごとにコスト調整パラメータが存在します。 ディスクからシーケンシャルアクセスで 8KB のデータを読み込む時間のコストを 1.0 とし、他の処理にかかる時間を相対値として表現されています。

各コスト調整パラメータの詳細は公式ドキュメントに記載されています。20.7.2. プランナコスト定数

例を挙げると以下のようなパラメータがあります。

• seq_page_cost: ディスクからシーケンシャルアクセスで 1 ページ分(8KB)のデータを読み込むために必要な時間コスト
• cpu_tuple_cost: ヒープデータ１行あたりの CPU 処理にかかる時間コスト
• cpu_index_tuple_cost: インデックスデータ１行あたりの CPU 処理にかかる時間コスト

再度、上記の実行計画を見てみましょう。

Seq Scan on users  (cost=0.00..22.17 rows=717 width=110)

シーケンシャルスキャンでデータを読み込むため、ディスク I/O のコスト(seq_page_cost=1.0)がかかります。 PostgreSQL ではページ単位でデータを読み取ります。コストを計算するためには、users テーブルの合計ページ数が必要です。 また読み取る行単位のデータ処理に必要な CPU コスト(cpu_tuple_cost=0.01)の和で算出することができます。

総コスト = (ディスクページ読み取り数 * seq_page_cost) + (スキャンした行 * cpu_tuple_cost)

以下のコマンドから users テーブルのページ数を確認できます。

$ SELECT relpages FROM pg_class WHERE relname = 'users';
relpages
15

relpages が 15 であるため、users テーブルの合計ページ数は 15 です。 上記の式に当てはめてみましょう。

総コスト = (15 * 1.0) + (717 * 0.01) = 22.17

計算結果と実行計画の総コストが一致していることが確認できました。 今回ではシーケンシャルスキャンのみを見てきましたが、インデックススキャンやハッシュジョインなども同様にコストを算出しています。

このように EXPLAIN では、実行されるクエリに必要な処理と、処理される行数を元にコストを算出しています。

まとめ

今回は PostgreSQL の EXPLAIN では、どのようにしてコストを算出しているかを紹介しました。 総コストはクエリに必要な処理と、処理される行数をもとに算出されます。これは当然ですが、運用していくことで読み取り対象の行数が増えるとコストも増えることを意味します。

初回の EXPLAIN の実行結果が安心できるものであったとしても定期的にチェックすることで、コストが増加していないかを確認できる仕組みをつくることが重要です。

参考文献

• PostgreSQL 14.5 文章 EXPLAIN の利用
• ［改訂 3 版］内部構造から学ぶ PostgreSQL―設計・運用計画の鉄則

リリース済みのプロダクトの場合、package.json に指定するバージョンは、一般的には固定値で指定するのが良いでしょう。 バージョンを固定することで破壊的な変更が入ったアップデートを意図せずリリースしてしまうことを防ぐことができるからです。

しかし新しくパッケージをインストールした際、うっかりこのバージョンを固定することを(僕は)忘れることがあります。今回はこれを防ぐためのツールを紹介します。

npm-package-json-lint

package.json の linter としてnpm-package-json-lintがあります。 これは package.json の記法が指定したルールに則っているかどうかをチェックするツールです。

npm-package-json-lint には package.json の記法に関する様々なルールを指定できますが、今回はバージョン固定についてのみ紹介します。他のルールについては公式ドキュメントを参照してください。

設定

設定ファイルの構築方法にはいくつかパターンがありますが、今回は一番簡単なnpmpackagejsonlint.jsonを配置する方法を紹介します。

repository のルートに npmpackagejsonlint.json を配置し、以下のように設定します。

{
    "rules": {
        "prefer-absolute-version": "error",
        "prefer-absolute-version-devDependencies": "error"
    }
}

今回は以下２つの設定を行いました。

• prefer-absolute-version は dependencies に指定されたパッケージのバージョンが固定になっているかをチェックします。
• prefer-absolute-version-devDependencies は devDependencies に指定されたパッケージのバージョンが固定になっているかをチェックします。

npm-package-json-lint の実行

今回は以下のような package.json を用意しました。

{
    "dependencies": {
        "react": "^18.2.0",
        "react-dom": "^18.2.0"
    }
}

ここでは react, react-dom のバージョンがチルダ表記で指定されています。 この状態だと patch 以下のバージョンが固定化されておらず、パッケージのインストール時に意図しないバージョンがインストールされる可能性があります。

ではこの状態で lint を実行してみましょう。すると以下のようなエラーが表示されるはずです。

❯ yarn npmPkgJsonLint .
✖ prefer-absolute-version-dependencies - node: dependencies - You are using an invalid version range. Please use absolute versions. Invalid dependencies include: react, react-dom
1 error
0 warnings

Totals
1 error
0 warnings
0 files ignored

エラーからはprefer-absolute-version というルールに違反していることがわかります。

それでは以下のようにバージョンを固定しましょう。

{
    "dependencies": {
        "react": "18.2.0",
        "react-dom": "18.2.0"
    }
}

これでエラーは解消されます。

❯ yarn npmPkgJsonLint .
✨  Done in 0.87s. # エラーが出ない

CI での実行

これを GitHub Actions などのワークフローに組み込むことで、バージョンが固定されていないパッケージをリリース前に発見することができます。 以下は GitHub Actions の CI ワークフローに追加した例です。

name: CI
on: [push]
jobs:
    lint:
        name: lint
        runs-on: ubuntu-latest
        timeout-minutes: 20
        steps:
            - uses: actions/checkout@v3
            - uses: actions/setup-node@v3
              with:
                  node-version-file: "package.json"
                  cache: "yarn"
            - run: yarn install
            - run: yarn npmPkgJsonLint .

CI のステップ内でnpm-package-json-lintを実行することで、package.json のルールに違反しているパッケージがあればエラーが出力されます。

これでコードレビュー時にバージョンが固定されていないパッケージが追加されていないか確認する必要がなくなりました。

関数名や変数を定義すると、このあと自分が書こうと思っていたコードが高い精度でサジェストされる。この「お前わかってるな」感が気に入りました。2023 年 1 月時点で Individuals プランであれば、月$10 だけど、体感 1 週間以内には払った金額は回収できると思った。 実際最近のインタビューで GitHub の CEO がCopilot を使っている開発者は、新規コードの 40％を Copilot で記述していると答えているのを見た。 数字を聞くと驚くが、一度 Copilot を使ってみるとこれくらいの数字でも違和感はない。

導入して 2 ヶ月弱、Copilot を使った実装にも慣れてきた。大分コツを掴んできた気がするので一度今の使い方をまとめてみる。(なおこの文章では Visual Studio Code での開発を想定している)

Codex: GitHub Copilot の本体

GitHub Copilot 自体はこの記事では詳しく紹介しないが、このサービスの裏側で動いているモデルについて軽く触れておきます。

GitHub Copilot は OpenAI の Codex というモデルを利用しています。今話題の ChatGPT で使われている GPT3 系列と同じ系列で、プログラムコードの生成に特化したモデルと言われています。 こちらの公式ドキュメントに Codex を使うにあたってのベストプラクティスが紹介されています。僕が感じたコツも概ねこれに沿ったものなっていたので、なんならこのドキュメントを読むだけ大体の勘所をつかめると思う。 Copilot を使い倒したいと思うなら読んで損はないでしょう。

Copilot のコツ

Copilot をペアプロ相手と考え、如何に正確に実装しようと考えている内容を相手に伝えるかを意識していくことが大事だと思います。 どのようにコードを書くことで Copilot に実装したい内容が伝えられるのかがだんだんわかるようになってきます。これが Copilot でのコツと言えるでしょう。

僕は最近 Copilot をペアプロ相手と考えるのが良いかなと思っている。自分が何をやりたいかをできる限り明確かつ具体的に伝えられるかが一番大事なコツと言えると思う。

明示的なコメントや関数名をつける

最も重要なコツの一つがどんなコードを書きたいのかを具体的かつ的確にコメントや関数名で表そうということです。

自分が指示を出される側になったと考えればイメージしやすいと思いますが、指示が曖昧であればあるほど何をアウトプットとして出せばよいかの期待がズレてしまうでしょう。 これは Copilot だって同じです。「なんかいい感じの処理をアレで実装しといて」くらい何も言ってないのと同義な指示を出されれば困ってしまいますよね。

このコツは単純に自分のプログラミングスキルを向上させることと同義かもしれません。人間が読んで理解しやすいコメント・関数名であれば、Copilot も正確にサジェストを出してもらう可能性が高まります。 一般的に読みやすいコードとはどういうものかについては、リーダブルコードなどの書籍で説明されている内容が該当するでしょう。

関数内にコメントを書く

Copilot は小さく切り出された関数のようにシンプルな処理に対しては精度高くサジェストしてくれるが、複雑な処理に対しては精度が下がる傾向にあります。とはいえ全ての処理を関数に分けるのは現実的ではありません。 関数内のコメントは、こういったケースで有用です。

関数内にコメントを書くことで、その処理内で実行したい処理に関する情報を追加して Copilot に伝えることができます。コンテキストやコードに対する意図が明確になればなるほど、サジェストされるコードの精度が上がります。

使ってほしい関数・ライブラリなどはコメントで指定する

特定のライブラリを使ってほしい場合は、そのライブラリを import しておくと、そのライブラリの関数をサジェストしてくれます。これはコメントに記述しておくことも有効です。

ライブラリと書いたが、自分のリポジトリ内の特定コードも同じ扱いです。

const awesome = require("./awesomeFunctions");

// create wonderful sort function to use awesome.sort
// ここ以降にサジェストが表示される

上記のようにコメント内に利用したい関数などを明示しておくことで、Copilot はその関数を使ったサジェストを表示してくれる可能性が高まります。

GitHub Copilot はリポジトリのどこまで読み込んでいるのか

Copilot の Q&Aには以下のように記述されています。

Code Snippets Data Depending on your preferred telemetry settings, GitHub Copilot may also collect and retain the following, collectively referred to as “code snippets”: source code that you are editing, related files and other files open in the same IDE or editor, URLs of repositories and files path.

お客様が希望する遠隔測定設定に応じて、GitHub Copilot は以下のものも収集・保持することがあります（総称して「コードスニペット」）：お客様が編集中のソースコード、関連ファイル、同じ IDE またはエディタで開いている他のファイル、リポジトリの URL、ファイルのパス。(DeepL による翻訳)

つまり現在編集中のファイルと、リポジトリ内に存在するそのファイルに関連するファイルを読み込んでいるようです。 ポイントはそのファイルに関連するファイルをどう判定しているかだが、確実なのは import などによって読み込んでいるファイルを関連ファイルと位置づけているということだろう。 使ってほしいファイルやライブラリについては、あらかじめ import で読み込んでおいたり、タブで開いておくなどしておくと Copilot がこれらを活用しより良いサジェストをしてくれます。

コメント内に複数の処理を並べて書くと、その処理をサジェストしてくれる

いくら関数名を工夫しても実現したい処理が複雑であればあるほど、適切に表現するのが難しいこともあります。これは関数として別で切り出す必要性の証拠かもしれませんね。

例えば処理の内容が数ステップに分かれているような場合は、それをコメントに記述しておくと Copilot はうまく理解し、反映したコードを提案してくれます。

上記の例ではコメントに従い、animalsとcitiesを定義し、storiesを返すようなコードをサジェストしてくれています。

実装者が処理の流れをうまくコメントに書けるかどうかで、サジェストの質が変わります。

コメントで指示を出す

Copilot は思っていた以上に柔軟にコメントを理解してくれます。 以下の例はコメントで特定の関数のユニットテストを書くように指示をしています。

この例ではsorArrayByDateという関数を実装されているという前提で、コメント内でこの関数に対してテストを書けと指示をしています。 Copilot はキチンとコメントの内容を読み取り、コメント上部に記述されているsorArrayByDateのテストコードを提案してくれます。

こういった指示出しはユニットコードの生成以外でも大いに有効です。例えば関数を実装する際に特定の構造体を利用指示したり、内部の処理で使用する関数を指定できたりします。

AI によるプログラミングのサポート

最近とにかく話題の ChatGPT ですが、これをエディタに組み込んでコーディングの補佐を担ってもらう拡張ツールも話題になっています。 ChatGPT は Copilot で使われているモデルと違い、対話型のモデルです。これまで触っていた所感だと、ChatGPT はよりリファクタリングや機能の追加といったユースケースで Copilot より融通がききます。

実は Copilot にもまだ β 版ですが GitHub Copilot Labs という experimental 版の拡張ツールが存在し、リファクタリングやテストコードの生成、ドキュメンテーションといった様々な機能を試すことができます。 これらはまだまだ荒削りな部分が多いですが、今後確実に精度を上がっていくでしょうし、AI によるプログラミングのサポートは今後ますます便利になっていくでしょう。 ソフトウェアエンジニアの一人としては、自分は今後エンジニアとしての価値をどこで発揮するかを真剣に考える必要があると感じています。

どう付き合っていくか

GitHub Copilot のようなツールは開発者にどのような影響を与えるかについて、公式の Q&A では以下のように回答されていました。

Bringing in more intelligent systems has the potential to bring enormous change to the developer experience. We do not expect GitHub Copilot to replace developers. Rather, we expect GitHub Copilot to partner with developers, augment their capabilities, and enable them to be more productive, reduce manual tasks, and help them focus on interesting work. We also believe that GitHub Copilot has the potential to lower barriers to entry, enabling more people to explore software development, and join the next generation of developers.

よりインテリジェントなシステムを導入することで、開発者のエクスペリエンスに大きな変化をもたらす可能性があります。私たちは GitHub Copilot が開発者に取って代わることを期待しているわけではありません。むしろ、GitHub Copilot は開発者のパートナーとなり、彼らの能力を増強し、より生産的に、手作業を減らし、興味深い仕事に集中できるようにすることを期待しています。また、GitHub Copilot は、ソフトウェア開発への参入障壁を低くし、より多くの人がソフトウェア開発を探求し、次世代の開発者に加わることを可能にする可能性を持っていると考えています。(DeepL による翻訳)

Copilot は開発者のパートナーであると言っていますが、これは僕個人の実感としても正しいと感じます。 Copilot が細かい実装の補助をサポートしてくれるので、自分は何を作るかにより集中できるようになりました。僕個人はCopilot を使い始めて、実装がなんだか楽しくなったなぁという気がとてもしますね。 なんとなく胡散臭さを感じて Copilot を使わない人もいるかもしれませんが、絶対もったいないです。ぜひ使ってみてください。

今後さらに Copilot のようなサポートツールが発展してくことが間違いないと思います。その中で単純に How を提供するソフトウェアエンジニアの価値は相対的に下がっていく危機感も同時に感じました。 エンジニアとしての価値をどこで発揮するかを考え抜き、自分の価値を高めていくことが大切だと思います。