Tech

はじめに 筆者はSIを生業とする企業で働いています。 お客様は比較的大きくて古い体質の企業様が多いです。 生成AI隆盛の現在ですが、予期せぬ学習されてしまうことを懸念して、あまり生成AIツールの導入に積極的ではありません。 そんな中でもGitHub CopilotはGitHub社の出しているサービスなので社内稟議も通りやすいらしく、使用が許可されています。 実際には他にも試してみたいツールはありますが、まずは職場で使えるツールに習熟しようということで、GitHub Copilotのドキュメントをローラーすることにしました。 今回の対象 GitHub Copilotのドキュメント GitHub Copilot全体の説明 使い方だけでなく、管理者としての設定もある Visual Studio Codeのドキュメント 主に使用者としてのドキュメント 筆者のOrgでは許可されていない機能も多いため、以下の主要な機能に絞って書いていきます。 対象 Chat Inline Chat Edits Completion 目線 開発者としてGitHub Copilotを使うこと 管理者の目線ではない 知らなかったこと Completionの使い方 私の普段の使い方としては以下の2つでした コードの書き出しを書いて、提案がいい感じだったらTabを押す コメントに要件を書いて、提案がいい感じだったらTabを押す 公式ドキュメントを読むともう少し奥深い使い方がありました。 ⌘ + ->で単語レベルの適用ができる Completion Panelを開くことで複数案の列挙ができる（画像の右側のペイン） モデルの話 公式ドキュメントによると、現在の既定のモデルはGPT 4oとのことでした。 また、以下のモデルへの変更も可能です Claude 3.5 Sonnet o1 o1-mini CursorやらClineやらが色んなモデルを選択できるのに比べてやや見取りする感じもしますが、セキュリティを気にするエンタープライズな企業に対しては安心感のあるチョイスになっている気もします。 また、o1モデルについては推論時間が長くなることも注意書きされています。 Copilotのベストプラクティスにもありますが、あくまでCopilotはコーディングの補助ツールなので、ライトなタスクをバッタバッタと倒していくことが想定されています。 そういう意味でも、回答の精度と生成時間を考慮して、4oが既定のモデルになっているのかなーと想像しました。 コンテキストの話 全般的なコンテキストの話 LLMのモデルに対して回答の要求をする場合、Promptを通して適切なコンテキストを提供することが大切です。 余計なことを教えるとそれに回答が引っ張られるし、情報が足りないと明後日の方向に回答が飛んでしまいます。 「Copilotを役立つ出力の導く」の項目を見ると、Copilotのコンテキストは以下のように決まるようです。 Completionの場合 開いているファイル Chat, Inline Chatの場合 開いているファイル 同一の会話の過去のやりとり コンテキスト変数(#file, @workspaceなど) そのため以下のようなことが推奨されています 関係ないファイルは閉じる Chat, Inline Chatは関係ない話題ならリレフッシュする コンテキスト変数で明示的にファイル等を指定する @workspaceの深掘り 「チャット参加者」という概念があるようです。和訳で変になっちゃってるパターンですね。 元々はエージェントという機能名だったようですが、昨今話題の自立型のエージェントと名前被りするのでこっちを変えたのかなと想像。...

Prompt Engineering Guideを読んだ。やっと入門できたかもしれない。

はじめに 『コード×AIーソフトウェア開発者のための生成AI実践入門』を拝読しました。 GPT-3あたりから、一般にも生成AIの認知が広がり、日々進歩が進んでいます。 多くの生成AIを搭載したツールが雨後の筍のごとく生まれ、そのどれもが非常に魅力的なデモで多く人々を魅了しています。 昨今では、「今後はエンジニアは不要になる」「SaaS is die」などと物騒なことも喧伝されるようにもなりました。 エンジニアの端くれとしてご飯を食べている自分としては、エンジニアという仕事がなくなってしまうと非常に困ります。 また、今年は育休を取ろうとしているのですが、エンジニアという職業が風前の灯火なのであれば、おちおち休んでいる暇ではありません。 一時的に妻の不興を買ってでもさっさと業界を逃げ出す準備が必要です。 そんな恐怖に駆られ手に取ったのが本書でした。 基本データ 書籍名 コード×AIーソフトウェア開発者のための生成AI実践入門 著者名 服部佑樹 出版年 2024/9/19 ISBN 978-4-297-14484-5 書籍リンク https://gihyo.jp/book/2024/978-4-297-14484-5 開始日 2025/1/6 読了日 2025/1/13 全体的な概要 GitHubでアーキテクトを務める著者（GitHub Copilotにも携わってる？）が、非常に現実的な目線で昨今のプログラミング周辺を取り巻く生成AIの実情について語っています。 書籍の冒頭から力強く、以下のように宣言してくれます。 結論から言えば、エンジニアの仕事がAIに完全に奪われることはないでしょう。むしろ、AIとの共存は私たちの仕事をより創造的で価値あるものに変えていく可能性を秘めています。 服部 佑樹. コード×AIーソフトウェア開発者のための生成AI実践入門 (p.27). 株式会社技術評論社. Kindle 版. その後は、 生成AIとコーディングを取り巻く現状 プロンプトエンジニアリングの基礎や実践 生成AIツールのタイプごとの活用戦略 生成AIと協働するためのコーディングスキル 組織として取り組むべきこと 細かなTips集 など多岐にわたる内容が触れられていました。 今までやってきたことをしっかり継続すべきと思えることもあれば、生成AI時代に大きく行動や意識を変えないといけないと思わされるポイントもあります。 いずれにせよ、生成AIの特徴を踏まえて、今後個人や組織がどのようなことをしていくべきかの羅針盤になる書籍と感じました。 個人的に気になったポイント 以下で個人的に気になったポイントをまとめていきます。 これは筆者の問題意識や現状とマッチしたものを取り上げているので、書籍の中で取り扱われ方と必ずしも比例するものではないのでご了承ください。 エンジニアが読みやすいコードはAIも読みやすいコード 全編通して、言葉を変えて「エンジニアが読みやすいコードはAIも読みやすいコード」という趣旨のことが何度も触れられていました。 いかに生成AIが処理できるコンテキストが増えようとも、ある程度巨大なコードベース全てをコンテキストに含めることは現実的ではありません。 仮にコンテキストに含めることができても、生成AIの原理上、推論に扱われる情報は確率的なものになるはずです。 また、多くの生成AIツールは検索と生成を組み合わせています。 検索に引っかかるコードを書くこともまた重要です。 そのため、 ファイル クラスや関数 各ブロック など各レベルで単一責任原則を意識したコードを整理しておくことが重要であることがわかりました。 これは生成AI以前から言われていますが、また新しい視点で考えさせられますね。 AIと協働しやすいコード AIがいじってもいい部分を明確にする 既存のコードを真似して新しいコードを生成することは得意ですが、既存のコードを改変する意思決定を行うことは苦手です。 服部 佑樹. コード×AIーソフトウェア開発者のための生成AI実践入門 (p.321). 株式会社技術評論社....

Hugo + Cloudflare Pagesを用いて作成しています