コード品質はどうなる？生成AIとの最適な協働とは？〜コード×AI疑問解消会〜

参加したので議事として残します。
https://findy.connpass.com/event/333534/?utm_campaign=&utm_source=notifications&utm_medium=email&utm_content=title_link

疑問: プロンプトを学ぶ必要はあるか?

• タスクの多様性と一回性を考えると、完璧なプロンプトを作る必要はない
• 即興で使い捨てのプロンプトを生み出し、AIとの対話を通じて出力を調整する能力が重視される

生成AIとの協働の信頼性について

AIの出力は信頼がおけない

• 嘘をつく（ハルシネーション）
• 命令を無視する（トークンが多いと精度低下する）
• 文脈をすっとばす
  ⇒ 人間の判断が必要

人間のレビュー能力も信頼がおけない（あまりフィーチャーされていない）

• 500行以上/時間のペースでレビューを行うと、欠陥の発見率が大幅に低下
• 一度にレビューする量が400行を超えると、欠陥を見つける能力が低下

対処方法について

• 使用者が一度にレビューできる量に分割して指示する
  ⇒ 開発言語×タスク難易度×技術者スキルで作ってもらうコード範囲は変わる

コードの分離

• AIのメリットはどんどんコード生成できるところだが、裏を返せばどんどん壊す可能性もある
• 変更に強いコードを作っていく必要がある
  • for文でネストが深いコードだと、AIが編集範囲が分からないので、ガード節（return/continue/break) などで、ネストを減らしAIに渡しやすいチャンクを作成する
  • アーキテクチャレベルだとオープンクローズテクニック。触れさせない規定のクラスを作成しておく？

体系的なリファクタリング手法の適用

• AIはリファクタリングが得意だが、抽象的にオープンクエスチョンで”リファクタリングしてください”だけだと一気にすべて改善しようとして、人間側のレビューが難しくなる
  3個、5個全部修正してくる、ここだけ取り入れたいやベストな買いでないときがある
• なるべくクローズドクエスチョンでリファクタリングの観点を絞る
• AIが学習しているであろうリファクタリングカタログなどの観点を活用し、AIにより具体的な提案を引き出す。効果的なリファクタリングと品質の高いコード開発につながる。
  https://refactoring.com/catalog/
  https://qiita.com/sho-naka/items/fd37c0cef35235b39b56
• インダストリーの知見があって、それをクローズドクエスチョンに変換できると、AIもその観点に沿って答えてくれてレビューが楽になり、負荷が下がる

テスト

テストをいきなり作成するのではなく、デシジョンテーブルを作ってから行う。
デシジョンテーブルをAIに作成してもらい、それをベースに優先度付けや足りない観点を足すのが良い。

まとめ

• 良いコードを書くというのは今もこれからも変わらない。
• 記述的かつ初見でも理解しやすい状態
• 比較的メジャーなバージョンのモジュールとかで書かれていると、AI の提案するコードとも親和性が高い

AI と協働していくときに AI をいかにカスタマイズして、他社とは違うエンジンでエンジニアの能力をレベルアップするのか？

• ファインチューニングが当たり前になってくると、AIに学習させるコードが大事になってくるがAIに食わせるコードが以外にない
• 最新にメンテされているのが良く、1日では用意できない。継続的に作っていく必要がある
• 競争優位として取り扱うことが必要になる
• チームとして作り上げていくのが大事

ディスカッション

自分でコード作成するかAIに任せるかの判断は？

• コミュニケーションしながら早い段階で見極める
• 下記でAIに任せられる範囲も変わる
  • タスクの難易度
  • モデルの更新
• ソリューションとして何が出ているかの観点で見て、学習できていないので自分のタスクと考える（フロントエンドは進化が早い
• 業界の進み具合を見て判断する。生成AIにも癖のようなものがあり、把握するとさらにスピードが速くなる？

AIを活用する上でのアンチパターンについて

• プロンプトエンジニアリングを作りこむのはよくない

• 大量のものをすべてのカテゴリに期待するのはよくない（いずれはできるようになるかもしれないが

• AI モデルとツールへの期待値っていうようなところも、正しく持つのが良い

  • ハルシネーションを起こすかどうかみたいなところのチェック機構の実行はツール側の問題
  • 不適切なタスクに対して、自分がそのツールとかモデルとかを著しく異なる期待値で使ってないかをスタート地点として考える事は重要

• アンチパターンはトークン長、ツールの成熟度によって異なるが、依存関係多いのを扱うのは苦手。まだ控えた方が良い。ある程度コンテキストを絞って対応してもらう。

• 現状依存関係が多いものは苦手（現状はハードルが高い

• ハルシネーションにもタスク分解が有効

• 日本語の力だけでなく、ロジカルに問題を分割していく問題解決能力?

下記を掛け合わせて把握する 何を？

• 分割したコンポーネントに何が含まれるのか
• AI がどのぐらいまでなら知っているのか

現状ベストなプラクティスはないが、

• AIに任せすぎず自分に主体を置いて進める
• 必要に応じてAIに依頼するタスクを細分化する

AIに食わせるコードの整備

• ドキュメンテーションに何が含まれるのかはチームとして整理した方が良い
• 生成AIによりコードをそのまま読むのは楽なるので、付け足す情報については、コードには書かれていないような細く、情報バックグラウンドの情報が重要
• そのような情報を正当化しておくと、コードの読解の時にもAIにより、奥深くまで理解できるようになる
• 逆に間違えるとノイズとなり理解が困難になる。
• 古い情報が残ったままになるのはよくない
• コメントの書き方とか何を書かないのかってところも含めて整理する時代
• なんかここは古いから、このコメントに騙されちゃダメよっていうのをレガシー保守してると、そういう感覚をお持ちの方もいらっしゃると思うんですけど、それはまあ伝えないと通用しないそうですね。

現状のAIの限界

現状、ノーコード、ローコードの作成でも、メンテナンスする人っていうのは必要。作り込むっていうカスタマイズのところだと確実にコードを見る人は必要になる
タスクの難易度　作りたいソリューションにもよる。
競争優位性とされている企業だと、やっぱりこの AI でできないところを探っていくっていうようなところで投資も必要になる

基本的にただ単に社内ツールの重りをしているだけっていうようなところだと、やっぱりその捉え方っていうところも経営者もそうですし、実際に組み立てる人としても必要なスキルセットっていうのが変わってくる中で、じゃあどうやってポジショニングしようか？っていう話にはなってくるかもしれないです。？

AIが書いたコードなのか人でで書いたコードなのか判別はつくのか？

つかない。エンジニアの生産性を図りたい意図だとしたら、コードの行数で貢献の価値は測れないのであまり意味がない。
git hubではコードの著作権は生成させたエンジニアに帰属させている。AI ではなく人間が書いたコードみなすのが、多分運用としては正しいと思っている。 AI が書いたからバグ多いです。書いたから分かりませんっていうのは通用しない。
会社として、統一した捉え方をして、エンジニアに説明責任を持たせるのは必要

AIの得意不得意

AIの生成するコードの弱点は？

ありまくり。
これって AI ってものすごい。我々丸め込んでやっぱり話しちゃうっていうところはずっと前から問題ですよね。どっかのタイミングでやっぱり回帰分析でさえ AI みたいなのに使って出てるプロダクトとかもありましたけどで、結局これって大規模言語モデルって言った時に本当に大規模言語モデルを使って正しい依存関係を持って正しいプロンプトを言ってこうやって出してください。って言ったら確実に AI ためやってくれるんですよ。

人間がそのプロンプトを提供しないから、もしくはその依存関係のデータを提供しないからっていう理由が一つと、ツールがそれを自動でやってくれないからっていう理由なんですよね。

なんでおそらくこの AI の得意不得意はというよりは AI はとりあえず情報出してある程度のところまでやってくれるとで、ツールが何をできないのか？っていう方に着目した方がもしかしたらいいかもしれないですよね。

で、その上で言うと、じゃあその今その弱点というか。どんな問題をはらむかっていうと、やっぱりその脆弱性を含むコードを出してくるんじゃないか？っていうところで、そこに関してはやっぱりリアルタイムでというよりは、そのある程度 CSD とかのパイプラインの中で研修していくっていうようなところもありますし、じゃあその GPR ライセンスを含むんじゃないかって。

問題はフィルタリングで解除すると解決すると、なんで結構この AI ができるっていうようなというよりはツールが何をその弱点をカバーしてくれてるのか、っていうようなところのほうが、重要な観点の役はします

開発個所や言語によって得意不得意はあるか？

コボルとか
ロジックを経由させるとかはあるが、
十分な知識を AI モデルが持ってないっていうところに起因する問題

C＃
ゲームエンジンはオープンソースの学習対象には多くない
AIでは知っている領域が少なくてハルシネーションをおこしやすい

質問タイム

コードの制度について、精製 AI が出力するコードの精度の出力量に相関関係があるのか否か？

ある。

複数のLLMを使ってどうやってデータ構造を決めて、決めていくのか？

複数のLLMでコードレビューはよい。
どうやってチームに共有するのかっていうところは重要。
自分の書いたコード以外もそういうようなレビューが通るようにするっていうところは 1 つのアイデアかなと思います。

で、3 番目作成したアプリケーション適切に生成ラインに伝えるためには、どのようなフォーマットで内容を記述すればいいとお考えですか？

リポジトリレベルのコードを一括で読ませる方法

現在はない。唯一の方法があるとしたらファインチューニングです。
しかし、必ずしも全部読み込ませるって事がいいことではないので、そこは判断が必要
認識していただいた上で必要な情報だけを渡す。もしくはRAGでちゃんと検索をした上で必要な文脈だけ渡すのが良い。

コード作成をする際の AI 学習させるために必要なもの。

メンテナンスされているコード

今後のプログラマーに必要な技術は何か？

下記のような指針を持つのは大事

• AIを上手に使いこなし、生産性を爆上げするプログラマになる
• AIができない領域を極めていく