(JSConf JP 2023) LLM (大規模言語モデル) 全盛時代の開発プラクティス

このPDFは「LLM全盛時代の開発プラクティス」というタイトルの資料で、baseballyama氏によって作成されました。内容は主に大規模言語モデル（LLM）を活用した開発プラクティスに関するものです。

主な内容は以下の通りです：

1. **GitHub Copilotについて**:
- Copilotの利用が増え、コード提案を受け入れてから精査する流れが一般的になった。
- インターネット接続がないと利用できないことが難点。
- Copilotは開いているファイルを参考にしてコードを提案し、統一されていないコードは提案の精度を低下させる。

2. **AIツールによる効率化**:
- AIレビューツールとFigma to Codeツールについて議論。
- AIレビューツールは一般的なアドバイスに留まり、具体的な自社ルールに基づいたレビューが求められる。
- Figma to Codeでは、自社のデザインシステムに基づいたUIコンポーネントの生成が理想だが、現実では汎用的なコンポーネントが生成される傾向にある。

3. **AIツールの活用法**:
- 現実の業務において、AIツールは自社特有のコンテキストを理解する必要があるが、これを達成しているツールは少ない。
- AIは新人のように扱うと理解しやすく、プロセスとデータを明確に教える必要がある。
- レビューワークフローを言語化し、AIツールに適用して、不足している情報を補う。

4. **LLMの実装と結果**:
- コーディングルールに基づき、GitHubのプルリクエスト（PR）に対して指摘や改善案を提案する。
- 正しい指摘がある一方で誤った指摘もあり、コーディング規約を日々確認する副次効果がある。
- Vue 3コンポーネントの実装では、Figmaとの往復が減り、作業時間が大幅に短縮された。

5. **実装前のプロセス**:
- 作業プロセスと必要なデータを言語化し、単純で工数の大きいプロセスを特定する。
- 静的検査で自動化できない場合は、GitHub Copilotなどの既存ツールで対処し、必要に応じてLLMを活用する。

6. **サービスの成長と将来的な展望**:
- OpenAIを中心としたLLMを使用したサービスの成長が著しい。
- 既存製品の活用と、将来的に解決される問題に対しては自作を控えるバランスが必要。

7. **プログラミング実装例**:
- Chat GPTに対して具体的な指示と必要なデータを提供し、期待値との差異を確認する。
- 指示とデータを修正し、プログラムを実装して運用を開始する。
- 具体的なコーディング規約違反の例を挙げ、その理由を詳述する。

この資料は、AIツールやLLMを活用した開発プラクティスに関する具体的なケーススタディと実装例を提供しており、現代のソフトウェア開発におけるAIの活用方法についての洞察を提供しています。

---

このスライド「LLM全盛時代の開発プラクティス」は、特にAIと大規模言語モデル（LLM）を現代のソフトウェア開発プロセスに統合する方法に関心がある方にとって非常に有用です。以下の点でその有用性が特に際立っています：

1. **現実的なAIツールの評価**:
- GitHub Copilotや他のAIレビューツール、Figma to Codeのようなツールの実践的な使用例とその限界についての詳細な分析を提供します。これは、これらのツールを日々の開発プロセスに統合しようと考えている開発者にとって役立つ情報です。

2. **実装の具体例と指針**:
- AIを効果的に活用するための具体的なステップと考慮事項を提供し、それによってAIの導入を検討する際の実用的なロードマップを提供します。

3. **プロセスの最適化**:
- AIツールの適切な使用による作業時間の削減や効率化の具体例を示しており、これは開発時間とリソースの割り当てについて考える際に非常に有用です。

4. **将来の展望と調整**:
- AIとLLMの急速な進化に伴う、既存のツールの選択とカスタムツール開発の間のバランスについての洞察を提供します。これは長期的な戦略計画において重要な考慮事項です。

5. **実際のコード例と実装**:
- 実際のコーディング規約違反の例とそれを解決するためのAIの使用例を含めており、具体的な事例を通じて理解を深めるのに役立ちます。

Transcript

1. LLM (大規模言語モデル)
 全盛時代の
 開発プラクティス
 baseballyama

2. 自己紹介 (baseballyama)
 • 株式会社フライル
 ◦ TypeScript / Vue / Svelte
 ◦ Kotlin / Spring Boot
 ◦ Python / Fast API / Open AI
 ◦ AWS / Terraform
 ◦ MySQL / Fargate / S3 / SQS / その他 
 
 • Svelteコアチームメンバー 
 ◦ Svelte5に向けて活動中 (できる範囲で)
 ▪ Svelte コンパイラのバグ修正
 ▪ ESLint Parser の Svelte 5 対応
 ▪ ESLint Plugin の Svelte 5 ルール追加
 ▪ コミュニティからの質問対応 
 
 • その他
 ◦ 本業では5月からLLM系の機能を主に担当しています 

3. 始める前に
 JavaScript の話
 薄めです。すみません。

4. 1. GitHub Copilot の話
 2. AIツールによる更なる効率化
 a. 理想と現実
 i. AIレビューツール
 ii. Figma to Code
 b. 理想と現実のギャップを埋める方法
 i. AIレビューツール
 ii. Figma to Code
 c. ギャップを埋める実装ステップ
 i. 実装する前に...
 ii. 実装ステップ
 3. まとめ
 アジェンダ

5. 1. GitHub Copilot の話
 2. AIツールによる更なる効率化
 a. 理想と現実
 i. AIレビューツール
 ii. Figma to Code
 b. 理想と現実のギャップを埋める方法
 i. AIレビューツール
 ii. Figma to Code
 c. ギャップを埋める実装ステップ
 i. 実装する前に...
 ii. 実装ステップ
 3. まとめ
 アジェンダ

6. 1. GitHub Copilot の話

8. ⚡アンケート⚡
 
 GitHub Copilot 使ってますか?

9. 個人的所感
 • 少しタイピングしたら数秒待って、サジェストされたコードをとりあえず Accept して その後精査する、という流れが基本になった
 (Vue.js / TypeScript / 独自ユーティリティ有でも問題なくサジェストされる)
 
 • 実装が面倒なユーティリティ関数はコメントだけ書いて GitHub Copilot に実装して 貰う、という場面も増えた
 
 • 飛行機などネットが使えないと GitHub Copilot が使えなくて辛い
 
 • Svelteコンパイラみたいな参考にできるコードが少ない系のプロジェクトではあまり 採用できない感覚

10. GitHub Copilot のサジェスト方法の説明
 const で統一
 function で統一
 const と function 混在

11. GitHub Copilot のサジェスト方法の説明
 • GitHub Copilot は現在開いているファイルを参考にサジェストする仕組みのようで す
 
 • よって、既存の実装が (不必要に) 統一されていない場合、サジェストの精度が落 ちてしまいます

12. コードの書き方の変化
 • つまり、「統一感」を重視している開発チームの場合、「統一感」はこれまでにも増し て重要になります。
 コードベースに統一感がない場合、GitHub Copilot がサジェストするコードも統一感 がなくなり、コードベースの統一感のなさが加速します。
 • (脱線: 外在性認知負荷) 個人的には「統一感」はチーム開発において重要な要素だと考えています。例 えば、先ほどの const vs function の例の場合、なぜここは const を使用しているのだろうか、なぜここは function を使用しているのか、という疑問を持つ開発者が出ることが予想されます。これは「外在性認知 負荷」と呼ばれます。つまりコーディングで達成したい目標と直接関係のない負荷です。このような認知負 荷は少ないほど良いはずです。 

13. どうやって統一感を獲得するか
 • ESLint などの静的検査ツールを徹底的に活用しましょう
 ◦ 必要に応じて ESLint のカスタムルールを作りましょう
 ◦ ESLint のカスタムルールを作る時間がない場合は
 一旦AIを使用したレビュープロセスを導入しましょう (詳しくは後述)
 
 • 過去の資産が多いなどの理由で既に統一感がない場合は
 ◦ まずはコーディングルールを策定しましょう
 ◦ ESLint の autofix などを活用して一括でリファクタリングしましょう
 ◦ 一括で対応するのが難しい箇所は、コードにTODOを貼りましょう

14. 先ほどの function にTODOを貼ると...

15. まとめ
 • GitHub Copilot は現在開いているタブのコードを参考にする
 • 良いサジェストを得るにはコードの統一感が重要
 • 統一感を獲得するためにはESlintなどの静的検査を導入する
 ◦ すぐにできない場合はTODOを貼るだけでも有効

16. 統一感は大事

17. 時間配分
 ヨシッ

18. 1. GitHub Copilot の話
 2. AIツールによる更なる効率化
 a. 理想と現実
 i. AIレビューツール
 ii. Figma to Code
 b. 理想と現実のギャップを埋める方法
 i. AIレビューツール
 ii. Figma to Code
 c. ギャップを埋める実装ステップ
 i. 実装する前に...
 ii. 実装ステップ
 3. まとめ
 アジェンダ

19. 1. a
 2. AIツールによる更なる効率化

20. 1. GitHub Copilot の話
 2. AIツールによる更なる効率化
 a. 理想と現実
 i. AIレビューツール
 ii. Figma to Code
 b. 理想と現実のギャップを埋める方法
 i. AIレビューツール
 ii. Figma to Code
 c. ギャップを埋める実装ステップ
 i. 実装する前に...
 ii. 実装ステップ
 3. まとめ
 アジェンダ

22. 例えば...
 AIレビューツール

23. 最近流行りのAIレビューツールを使ってみた
 Figma to Code
 AIレビューツール

24. 最近流行りのAIレビューツールを使ってみた
 
 「テストを追加しよう」とか「コメントを書きましょう」 
 とかごく一般的なことしか指摘してくれなかった。 
 
 テストは別の方法で対処しているので問題ないし、コメントはほとんどの場 合はコメントを読めばわかるので、不必要に書く必要はないと考えている。 
 
 もっと実際に役立つ指摘をして欲しい。 
 Figma to Code
 AIレビューツール

25. 最近流行りのAIレビューツールを使ってみた
 理想 : 自社のルールやコンテキストを踏まえてレビューして欲しい
 現実 : 一般的な指摘に終始する
 Figma to Code
 AIレビューツール

26. (参考) LLMを使用したレビュー支援ツール
 • PR-Agent (https://github.com/Codium-ai/pr-agent ) (⭐2.6K)
 • AI-based PR reviewer and summarizer (⭐1K)
 (https://github.com/coderabbitai/ai-pr-reviewer )
 • chatgpt-action (⭐556) (https://github.com/kxxt/chatgpt-action#chatgpt-action )
 • ChatGPT Code Review (⭐191) (https://github.com/domvwt/chatgpt-code-review#chatgpt-code-review )
 • AI Code Reviewer (https://github.com/freeedcom/ai-codereviewer ) (⭐144)
 Figma to Code
 AIレビューツール

27. 例えば...
 Figma to Code

28. Figma to Code
 • 自社特有のデザインシステムがあるから単に HTML / CSS が出てきても困る
 
 • Figma公式のコード生成はReactのみ
 
 • Builder.io は色々なライブラリに対応している
 しかし自社向けなカスタマイズがどこまでできるかは不明
 Figma to Code
 AIレビューツール

29. Figma to Code
 理想 : 自社のコンテキストを踏まえたUIコンポーネントを出力して欲しい
 現実 : コンテキストを踏まえないUIコンポーネントが出力される
 Figma to Code
 AIレビューツール

30. AIツールの理想と現実
 現実の業務でAIツールを活用するには、AIツールは自社特有のコンテキストを理解する 必要があるが、現時点でこれを達成しているツールはあまりないと理解しています。
 
 これは以下2つのどちらかの方法で解決する必要があります
 1. 自動的に自社特有コンテキストを理解するAIを実装する (AGIに近い (?))
 2. 我々がAIに自社特有のコンテキストを与える
 
 今回は 2 の方法に関して具体的な経験を共有します。

31. 2. 理想と現実を埋める方法

33. 最初に結論
 AIはめちゃくちゃ知識があるが業務のことを何も知らない新人だと思うとわかり やすいと思います。
 プロセスとデータを解釈の余地なく教える必要があります。
 Figma to Code
 AIレビューツール

34. LLMと人間の違い
 共通点
 • LLMは人間の脳の仕組みを模倣している
 相違点
 • 知識獲得方法
 ◦ 人間 : (個人・組織に関わらず) 各々が十人十色の経験を基に独自の知識を獲得している 
 ▪ 知識量は限られているが独自性に優れている 
 ◦ LLM : webから収集できる一般的な知識を獲得している 
 ▪ 知識量は膨大だがwebから収集できない独自情報は知らない 
 一番わかりやすい例は「あれどうなった?」で理解できるのが人間。
 LLMは理解できない。
 Figma to Code
 AIレビューツール
 免責 : 私はAI / LLM の専門家ではないため正確でない可能性があります。 

35. LLMと人間の違い
 つまり、LLMは、私たちが普段意識することもなく共通認識とみなしているアレやコレを 知らない訳です。
 これはまさに会社に来た新人と似ている状況ではないでしょうか。
 Figma to Code
 AIレビューツール
 免責 : 私はAI / LLM の専門家ではないため正確でない可能性があります。 

36. AIは新人
 (めちゃくちゃ知識豊富だけど)

37. AIレビューツールの理想と現実を埋める方法
 理想 : 自社のルールやコンテキストを踏まえてレビューして欲しい
 現実 : 一般的な指摘に終始する
 理想に近づけるためには 
 1. まずはレビューのワークフローを言語化する
 2. その後、AIレビューツールにそのワークフロー通りに処理させる
 3. 各ワークフローで足りない情報があればAIに教える
 Figma to Code
 AIレビューツール

38. AIレビューツールの理想と現実を埋める方法
 やってみた結果
 Figma to Code
 AIレビューツール

39. AIレビューツールの理想と現実を埋める方法
 やってみた結果
 結果
 • 自社のコーディングルールを基に
 • GitHub のPRに対して指摘
 • 改善案も提案
 
 効果
 • 正しい指摘もある一方で誤りもある
 • コーディング規約を日々目にするようになると いう副次効果
 
 改善点
 • まだ false positive も多い
 • 本当に修正が必要な指摘だけをできるように ならないと狼少年になって人間に無視される ようになる
 Figma to Code
 AIレビューツール

40. リポジトリはここに (ai-review-flex)
 https://github.com/baseballyama/ai-review-flex 
 Figma to Code
 AIレビューツール

41. Figma to Code の理想と現実を埋める方法
 理想 : 自社のデザインシステムを踏まえて自動生成して欲しい
 現実 : 単にライブラリを使用したコードが生成されてしまう
 理想に近づけるためには 
 1. まずはレビューのワークフローを言語化する
 2. その後、AIレビューツールにそのワークフロー通りに処理させる
 3. 各ワークフローで足りない情報があればAIに教える
 Figma to Code
 AIレビューツール

42. Figma to Code 理想と現実を埋める方法
 やってみた結果
 Figma to Code
 AIレビューツール

43. Figma to Code の理想と現実を埋める方法
 やってみた結果
 結果
 • 自社のデザインシステムコンポーネントを基に
 • Vue 3 コンポーネントを実装してくれた
 
 効果
 • Figmaと行き来する回数が大幅に減った
 • 今まで30分程度はかかっていただろう作業が5 分足らずで大枠が出来るのはかなり楽になっ た。
 
 改善点
 • 生成したコードに対して vue-tsc や ESLint を実 行してエラーがなくなるまで自動修正させれば もっと手作業が減りそう。
 (時間が足りなくて試せませんでした🙏)
 
 Figma to Code
 AIレビューツール

44. 公開リポジトリはありません。
 Figma to Code
 AIレビューツール

45. 3. ギャップを埋める実装ステップ

47. 実装する前に...

48. a. 実装する前に...
 実装する前に以下の手順を踏むのが良いと思います。
 作業プロセスと必要なデータを言語化する 
 ”単純作業” で “工数大” なプロセスを抽出する 
 静的検査で自動化 できるか
 自動化する
 Yes
 GitHub Copilot などの既存ツールで対処する 
 GitHub Copilot
 などの既存ツールで 対処できるか
 Yes
 LLM を活用して独自の対処方法を検討する 
 No
 Yes
 No

49. a. 実装する前に...
 実装する前に以下の手順を踏むのが良いと思いました。
 作業プロセスと必要なデータを言語化する 
 ”単純作業” で “工数大” なプロセスを抽出する 
 静的検査で自動化 できるか
 自動化する
 Yes
 GitHub Copilot などの既存ツールで対処する 
 GitHub Copilot
 などの既存ツールで 対処できるか
 Yes
 LLM を活用して独自の対処方法を検討する 
 No
 Yes
 No
 LLMはいわば「異様に能力が高いがプロジェクトのことを何も知らない人」です。
 LLMへの指示は「解釈の余地なく」出す必要があります。
 つまり、自動化したいタスクを解釈の余地なく言語化できる必要があります。
 また、LLMはプロジェクトのことを何も知りません。よって、その作業プロセスに必要なデータ も全て言語化する必要があります。

50. a. 実装する前に...
 実装する前に以下の手順を踏むのが良いと思いました。
 作業プロセスと必要なデータを言語化する 
 ”単純作業” で “工数大” なプロセスを抽出する 
 静的検査で自動化 できるか
 自動化する
 Yes
 GitHub Copilot などの既存ツールで対処する 
 GitHub Copilot
 などの既存ツールで 対処できるか
 Yes
 LLM を活用して独自の対処方法を検討する 
 No
 Yes
 No
 LLMは「高い」「遅い」「不正確」なので、ロジックで対 処できるものは全てロジックで対処した方が良いで す。

51. a. 実装する前に...
 実装する前に以下の手順を踏むのが良いと思いました。
 作業プロセスと必要なデータを言語化する 
 ”単純作業” で “工数大” なプロセスを抽出する 
 静的検査で自動化 できるか
 自動化する
 Yes
 GitHub Copilot などの既存ツールで対処する 
 GitHub Copilot
 などの既存ツールで 対処できるか
 Yes
 LLM を活用して独自の対処方法を検討する 
 No
 Yes
 No
 OpenAI を中心として、LLMを使用したサービスの成長速度が凄まじいです。
 折角自作してもすぐに既存製品が対応する可能性があるので、
 現時点では、既存製品を積極的に使用すると共に各社の動向を見て、製品側で対応さ れることで将来解決されそうな問題に対しては、自作するとしても深追いしすぎないなど の塩梅の調整が必要です。

52. a. 実装する前に...
 実装する前に以下の手順を踏むのが良いと思いました。
 作業プロセスと必要なデータを言語化する 
 ”単純作業” で “工数大” なプロセスを抽出する 
 静的検査で自動化 できるか
 自動化する
 Yes
 GitHub Copilot などの既存ツールで対処する 
 GitHub Copilot
 などの既存ツールで 対処できるか
 Yes
 LLM を活用して独自の対処方法を検討する 
 No
 Yes
 No
 それでも独自の方法が必要であるという結論に至った場合は
 LLMを活用して独自の仕組みを実装しましょう!!

53. 作らない

54. LLMを活用して独自の仕組みを実装する場合は...

55. b. 実装ステップ
 私が今まで試した中では以下の手順が良いと思いました。
 Chat GPT に指示と必要なデータを与える 
 差分に関して
 なぜそのような回答をしたのかを聞く 
 指示とデータを修正して再度処理させる 
 返答と期待値に
 差分があるか
 Yes
 Chat GPT にこれまでの指示をまとめさせる 
 新しいチャットにて、まとめた指示に対して 
 不明瞭な点や疑問がないかを聞く 
 (あればこれらがなくなるまで修正する) 
 この指示を使用するプログラムを実装する 
 返答と期待値に
 差分があるか
 運用開始
 ※ 全指示とレスポンスはログに保存しておく 
 Yes

56. b. 実装ステップ
 私が今まで試した中では以下の手順が良いと思いました。
 Chat GPT に指示と必要なデータを与える 
 差分に関して
 なぜそのような回答をしたのかを聞く 
 指示とデータを修正して再度処理させる 
 返答と期待値に
 差分があるか
 Yes
 Chat GPT にこれまでの指示をまとめさせる 
 新しいチャットにて、まとめた指示に対して 
 不明瞭な点や疑問がないかを聞く 
 (あればこれらがなくなるまで修正する) 
 この指示を使用するプログラムを実装する 
 返答と期待値に
 差分があるか
 運用開始
 ※ 全指示とレスポンスはログに保存しておく 
 Yes

57. LLMを活用して独自の仕組みを実装する場合は...

58. 指示とデータを与える
 あなたは世界を代表するソフトウェアエンジニアです。あなたの仕事は git の diff をよく理解し、コーディング規約に違反しているコード を指摘することです。
 以下のコーディング規約とdiffを基に指摘してください。
 
 ## コーディング規約
 
 ### プロダクションコードにコンソールログを残さない
 
 本番コードからすべての `console.log` ステートメントを削除することで、情報の漏洩や出力の乱雑さを避けることができます。
 
 ## diff
 
 {{ git diff の結果 }}

59. 回答
 Based on the coding standards you provided and the `diff` content, there is a clear issue that needs to be addressed:
 
 The addition of `console.log(diff);` in the `splitForEachDiff` function violates the coding standard of not leaving console logs in production code. As per the standard, all `console.log` statements should be removed from production code to avoid information leakage and cluttered output. This newly introduced line directly contravenes this rule and should be removed or replaced with an appropriate logging mechanism suitable for production environments.
 英語で返ってきたので日本語にしたい

60. 指示とデータを修正する
 日本語で回答してください。

61. 回答
 コーディング規則に基づいて、提供された `diff` の内容を検討すると、以下の問題点が明確になります：
 
 `splitForEachDiff` 関数に追加された `console.log(diff);` は、本番コードにコンソールログを残さないという規則に違反しています。規則 によれば、情報漏洩や出力の乱雑さを避けるために、本番コードからすべての `console.log` ステートメントを削除する必要があります。 この新しく追加された行はこのルールに直接反しているため、削除されるか、本番環境に適した適切なロギング機構に置き換えられる べきです。
 最初の文章は不要

62. 指示とデータを修正する
 指摘だけを簡潔に返答してください。

63. 回答
 `splitForEachDiff` 関数に追加された `console.log(diff);` は本番コードにコンソールログを残さないというコーディング規約に違反してい ます。この行は削除すべきです。
 よさそう

64. これまでの指示をまとめる
 これまでの指示を整理してください。この指示はGPTへの命令に使用します。指示は解釈の余地がないようにしてください。

65. 回答 (1 / 2)
 
 以下に、あなたがLLMに対して使用するための整理された命令を示します。これは、コーディング規約とdiffが変わることを考慮して変数 として設定できるように構成されています。
 
 ---
 
 ### 命令のテンプレート
 
 **命令:**
 LLMに対して、特定のコーディング規約に基づいて、提供されたdiffの内容を分析し、規約違反がある場合はその指摘を行う。
 
 **変数:**
 1. `codingStandard`: コーディング規約の詳細（テキスト形式）。
 2. `diffContent`: 分析するdiffの内容（テキスト形式）。
 

66. 回答 (2 / 2)
 
 **具体的な指示:**
 1. LLMは、`codingStandard` に示されたコーディング規約を理解し、遵守する。
 2. LLMは、`diffContent` を分析し、`codingStandard` に違反している部分があるかどうかを判断する。
 3. もし規約違反がある場合、LLMはその具体的な違反点と、それがどのように規約に反しているかを明確に指摘する。
 4. 分析結果は簡潔かつ明確に提示する。
 
 ---
 
 このテンプレートを使用することで、LLMに対する指示を明確かつ一貫性を持たせることができます。また、変数を変更することで、異な るコーディング規約やdiff内容に対応することが可能です。

67. b. 実装ステップ
 私が今まで試した中では以下の手順が良いと思いました。
 Chat GPT に指示と必要なデータを与える 
 差分に関して
 なぜそのような回答をしたのかを聞く 
 指示とデータを修正して再度処理させる 
 返答と期待値に
 差分があるか
 Yes
 Chat GPT にこれまでの指示をまとめさせる 
 新しいチャットにて、まとめた指示に対して 
 不明瞭な点や疑問がないかを聞く 
 (あればこれらがなくなるまで修正する) 
 この指示を使用するプログラムを実装する 
 返答と期待値に
 差分があるか
 運用開始
 ※ 全指示とレスポンスはログに保存しておく 
 Yes

68. まとめた指示に対して不明瞭な点や疑問がないかを聞く
 以下の指示に関して、不明点や不明瞭な点があれば教えてください。 
 
 ---
 
 **命令:**
 特定のコーディング規約に基づいて、提供されたdiffの内容を分析し、規約違反がある場合はその指摘を行う。 
 
 **変数:**
 1. `codingStandard`: コーディング規約の詳細（テキスト形式）。 
 2. `diffContent`: 分析するdiffの内容（テキスト形式）。 
 
 **具体的な指示:** 
 1. LLMは、`codingStandard` に示されたコーディング規約を理解し、遵守する。 
 2. LLMは、`diffContent` を分析し、`codingStandard` に違反している部分があるかどうかを判断する。 
 3. もし規約違反がある場合、LLMはその具体的な違反点と、それがどのように規約に反しているかを明確に指摘する。 
 4. 分析結果は簡潔かつ明確に提示する。 

69. 回答
 承知しました。このタスクを実行するためには、以下の情報が必要です：
 
 1. **コーディング規約の詳細** (`codingStandard`)：これは、分析する際に参照するルールセットです。コーディング規約の詳細が提供 されているか、あるいは特定の既存のコーディング規約（例えばPEP 8、Google Java Style Guideなど）を参照するかの指示が必要で す。
 
 2. **分析するdiffの内容** (`diffContent`)：これは、変更点を示すコードの差分（diff）です。diffがどのように表示されているか（例えば、 GitHub形式のdiff、単純なテキスト比較など）、そしてどのプログラミング言語で書かれているか（TypeScript、JavaScript、Kotlin、Java、 Pythonなど）の情報が必要です。
 
 これらの情報を提供していただければ、指示に従って分析を行うことができます。どうぞよろしくお願いいたします。

70. 大丈夫そうなのでコードに落とし込んでみましょう。 

71. コードにしてみる
 const response = await openai.chat.completions.create({
 model: "gpt-4-1106-preview" ,
 messages: [
 {
 content: buildPrompt(codingRule, diff),
 role: "user",
 },
 ],
 temperature: 0,
 });
 return response.choices[0]?.message?.content ?? "";
 
 const buildPrompt = (
 codingStandard: string,
 diffContent: string,
 ) => {
 return `\
 **命令:**
 特定のコーディング規約に基づいて、提供されたdiffの内容を分析し、規約違反がある場合はその指摘を行う。
 
 **変数:**
 1. \`codingStandard\`: コーディング規約の詳細（テキスト形式）。
 2. \`diffContent\`: 分析するdiffの内容（テキスト形式）。
 
 **具体的な指示:**
 1. LLMは、\`codingStandard\` に示されたコーディング規約を理解し、遵守する。
 2. LLMは、\`diffContent\` を分析し、\`codingStandard\` に違反している部分があるかどうかを判断する。
 3. もし規約違反がある場合、LLMはその具体的な違反点と、それがどのように規約に反しているかを明確に指摘する。
 4. 分析結果は簡潔かつ明確に提示する。
 5. 日本語で回答する。
 
 ## codingStandard
 ${codingStandard}
 
 ## diffContent
 ${diffContent}`;
 };
 
 指示が抜けていたので足しました。 

72. コードにしてみる
 const response = await openai.chat.completions.create({
 model: "gpt-4-1106-preview",
 messages: [
 {
 content: buildPrompt(codingRule, diff),
 role: "user",
 },
 ],
 temperature: 0,
 });
 return response.choices[0]?.message?.content ?? "";
 const buildPrompt = (
 codingStandard: string,
 diffContent: string,
 ) => {
 return `\
 **命令:**
 特定のコーディング規約に基づいて、提供されたdiffの内容を分析し、規約違反がある場合はその指摘を行う。
 
 **変数:**
 1. \`codingStandard\`: コーディング規約の詳細（テキスト形式）。
 2. \`diffContent\`: 分析するdiffの内容（テキスト形式）。
 
 **具体的な指示:**
 1. LLMは、\`codingStandard\` に示されたコーディング規約を理解し、遵守する。
 2. LLMは、\`diffContent\` を分析し、\`codingStandard\` に違反している部分があるかどうかを判断する。
 3. もし規約違反がある場合、LLMはその具体的な違反点と、それがどのように規約に反しているかを明確に指摘する。
 4. 分析結果は簡潔かつ明確に提示する。
 5. 日本語で回答する。
 
 ## codingStandard
 ${codingStandard}
 
 ## diffContent
 ${diffContent}`;
 };
 
 指示が抜けていたので足しました。 

73. 実行してみた (1 / 2)
 ## 分析結果
 
 ### 規約違反の指摘 
 
 **違反箇所:** 
 ```diff
 + console.log(diff); 
 ```

74. 実行してみた (2 / 2)
 **違反理由:** 
 提供されたコーディング規約には「プロダクションコードにコンソールログを残さない」という指示が含まれていま す。この規約は、本番コードからすべての `console.log` ステートメントを削除することで、情報の漏洩や出力の乱 雑さを避けることを目的としています。提供された `diffContent` の変更部分には、新たに追加された `console.log(diff);` という行があり、これは明確にコーディング規約に違反しています。 
 
 ### 修正提案
 
 この `console.log` ステートメントは削除するか、デバッグ目的であれば、別のログメカニズムに置き換えることが 望ましいです。例えば、ロギングフレームワークを使用して、開発環境でのみログを出力する設定にすることが考 えられます。

75. いい感じですね。
 (ちょっと回答が長いけど)

76. 実際にはこんなことも実装しないといけない...
 • コーディング規約のファイルをルールごとに split する処理 
 • diff を取得して1箇所ごとに分割する処理 
 ◦ diff から削除行を削除する処理 (これをした方が精度が上がった) 
 • 回答フォーマットをより厳密にするプロンプト調整 
 ◦ 指摘対象の diff に対してコメントするためには指摘対象の行番号が必要 
 • GitHub にコメントを投稿する処理 
 • 並列処理 (GPT4 は遅いため) 
 • OpenAI API のレート制限に引っかかった場合のリトライ処理 
 
 などなど...

77. 実装ステップ
 私が今まで試した中では以下の手順が良いと思いました。
 Chat GPT に指示と必要なデータを与える 
 差分に関して
 なぜそのような回答をしたのかを聞く 
 指示とデータを修正して再度処理させる 
 返答と期待値に
 差分があるか
 Yes
 Chat GPT にこれまでの指示をまとめさせる 
 新しいチャットにて、まとめた指示に対して 
 不明瞭な点や疑問がないかを聞く 
 (あればこれらがなくなるまで修正する) 
 この指示を使用するプログラムを実装する 
 返答と期待値に
 差分があるか
 運用開始
 ※ 全指示とレスポンスはログに保存しておく 
 Yes

78. 運用開始 ※ 全指示とレスポンスはログに保存しておく
 プロンプトを一度作っただけでは大抵うまくいきません。こういうケースではうまくいくけどこういうケースではうまく いかない、のような学びを得ることになります。 
 その度にプロンプトを改善する必要があります。 
 
 プロンプトを改善する方法は簡単です。単に「その回答をした理由を教えてください」と聞きましょう。 

79. 運用開始 ※ 全指示とレスポンスはログに保存しておく

80. 運用開始 ※ 全指示とレスポンスはログに保存しておく

81. 運用開始 ※ 全指示とレスポンスはログに保存しておく
 OpenAI の Playground を使用すれば Assiatants に任意の回答をさせた体でプロンプトを実行できます。 

82. 運用開始 ※ 全指示とレスポンスはログに保存しておく
 これをひたすら繰り返すことで精度改善をしましょう。 

83. 継続的改善

84. 他に有用なテクニック
 • プロンプトエンジニアリング : ( https://www.promptingguide.ai/ )
 • ロール設定 : 「あなたはxxxの専門家です」 (https://platform.openai.com/docs/guides/text-generation/chat-completions-api )
 • EmotionPrompt : 「限界を超えましょう!」 ( https://arxiv.org/abs/2307.11760 )
 • Assistants API : 知識の埋め込み
 • ベクターDB : より柔軟な知識の埋め込み 
 • Fine Tuning : モデルのカスタマイズ 
 GPTが知らない知識も使える 
 → 最新の技術はGPTが知らないから採用しない、の ようなことは気にする必要はない。 

85. テストに関して
 一般的にLLMの回答は毎回異なります。よってテストが難しいです。 
 LLMを使用した機能のテストに関してはまだ世界的にも手法が確立されていません。 
 それでも自分の経験から共有できることを共有しようと思います。 
 
 GPT モデルでは、パラメーターを設定することができるのですが、その中に「temperature」と呼ばれるパラメーター があります。
 
 これを設定すると、「最も確率の高い次のトークン」をひたすら返答し続けるので、プロンプト実行ごとの回答のブレ が (ある程度) 少なくなります。 
 
 よって、この性質を利用することで、「めちゃくちゃ精度が落ちた」のようなことに気づける状態を構築することがで きます。

86. テストに関して
 弊社ではこれをCIに組み込むことで品質劣化がないかを確認しています。 

87. まとめ

88. まとめ
 • (統一感は大事) AIの支援を最大化するために 統一感がより重要になります 
 • (AIは新人) AIは何も知らない新人です。 プロセスとデータを解釈の余地なく教える必要がありま す
 • (作らない) AIの進化が激しいので不用意に独自のツールを作っても無駄になる可能性があります 
 • (継続的改善) プロセスとデータを解釈の余地なく教えるのは至難の技です。例えば誰かが「明日の朝まで に」と言った時にAさんは「日本時間の朝までに」と捉えるかもしれませんし、Bさんは「サンフランシスコの朝 までに」と捉えるかもしれません。 
 よって、「継続的改善」が必須です。

89. 終わり良ければ全て
 ヨシッ
 ありがとうございました