AIがコード書きすぎ問題にはAIで立ち向かえ- 爆速開発時代のDevSecOpsを支えるパイプライン

はい じゃあセッションを始めさせていただきます
皆さんもそろそろモノ太郎の歌が歌えるようになっているんじゃないかと思いますか
私 AIが高度化きすぎ問題には AIで立ち向かいというセッションです
GitLabのソリューションアーキテクトをやっています
吉瀬と申します
一応私の経歴書いてあるんですけども
もともとどっちかというとインフラエンジニアですね
HPからニュータニックスというところで
インフラエンジニアだと自分では思っています
ただインフラってアプリケーションのためにあるので
アプリケーション開発者がどう気持ちよくアプリケーションをデプロイしてもらうかというところを
常に考えてインフラやってきました
今年GitLabに入社しましてやることいっぱいありすぎて大変ですという感じですね
一応ガーファー社長というのも書いてますけど
これテクロックフェスティバルという音楽フェス
エンジニアだらけの音楽フェスをやってまして
今年3年目なんですけど今回3Dsで1日目先週ちょうど終わって私も出たんですけど
これ楽しいのであと2日目3日目あるのでぜひ皆さん来てください
あとバンドやりたいなという方来年からまた参加していただければと思います
今日のアジェンダなんですけどもAIがコード書きすぎ問題についてプラットフォームが何ができるかみたいな話をしていきたいと思います
一応ディスクレーマーなんですけども
今日私スポンサー枠じゃなくて野生のエンジニア枠なので
ただ私の仕事GitLabのプリセールスですので
どうしても入社してからこの4ヶ月
毎日泣きながらGitLab触ってるんで
どうしてもそっちによった話になりがちですけども
別に今日はGitLab売るのが目的で来てるわけじゃないですと
どっちかというとAI推しの立場です
この資料にはAIはちょっとだけ使いました
GitLabっていうのが何回か出てくると思うんですけども
GitLabっていうプロダクトっていう意味はもちろんあって
そのプロダクトは統合DevSecOpsプラットフォームですという風にGitLabは言ってます
そのプロダクトを開発するGitLabっていう会社が
プラットフォームエンジニアリングを実践するっていうことは
要するにGitLabに機能を追加するっていうことなんですね
GitLabでGitLab作ってるんで
なのでその2つの意味合いがこの後の話で混ざってくるかもしれません
AIがコード書きすぎ問題ですね
GitHubコパイロットこれ2000万人
カーソルが100万人
チャットGPTは1週間で8億人らしいですよ
すごいですね
チャットGPTコーディングに使ってる人もまあまあいるんじゃないかなと思ってて
あとクロードコードもすごい流行ってますよね
私も使ってるんですけども
アンソロピックはオープンAIの倍のシェアっていうことで
相当な人がAI使ってコード書いてるよねっていう話
ちなみにGitLabにももちろんAIの機能があってGitLab Duoって言うんですけど
その後ろのLLMってアンソロピックなんで
こんな感じでこんな感じでみんな使ってますと
5%向上とかプロリクのサイズが18%増えてますとか
まあまあどんどん加速してます
ただこの数字って体感からするとかなり控えめだなっていう感じしてて
実際自分でそのクロードコードとか使ってコード書いてると
もうスピードなんて倍どころじゃないですよね
もう4,5倍もっとかなみたいな感じなんで
この感じで報告されてるっていうことは
まああんまりそれを言いたくないっていうのが一つと
あとは他にボトルネックがあるんじゃないかなっていう話ですね
じゃあAIコーディングツール
まあ超便利ですと
超便利なんですけどそれで皆さん幸せですか
特にプラットフォームエンジニアの皆さん幸せですかっていう話なんですけども
ソフトウェア開発者もそうですね
みんなが幸せになれたか
まあクソコードがまあまあね
すごいんですよ
だからコードのGit Clearの調査ですけど
コードの重複が4倍
まあいらんコードがめっちゃ吐かれるとか
それをコピペしちゃってるとか
まあそういう話があって
まあまあクソコード吐きますと
でレビュー地獄ですね
まあコードの量が増えるっていうことは
レビューの量もそりゃ増えるので
でしかもAIが書いたコード
何も考えずにそのままコミットしちゃったりすると
そもそもこれなんでこのコード書かれてるのかな
パッと見通せない
まあそういうコードがどんどん大量に吐かれてきて
まあレビュー地獄になってますと
でまあ幸せになれるはずが
まあこんな感じになっちゃってますと
いうところです
あの結構現場からの悲鳴っていうのは
まあ割とXとかでも目にするようになってきましたと
でこれはGitLabが調査した
GitLabがまあ世界中の企業に
調査会社に依頼して調査したやつなんですけども
ソフトウェアエンジニアって
えっと1日中コード書いてるのかっていうとそうじゃなくて
実はコード書いてる時間って
21%しかないですと
残りの時間何やってるかっていうと
そのコードが何やってるか理解する
まあレビューとかですね
あと既存のコードの改善
まあ間違ってたものを直すとか
トラブルシュートとか
まああともちろん
ミーティングとかそういうのもあると思うんですけども
まあ21%ぐらいしかコード書いてないですと
じゃあこの21%の部分の生産性が
例えば5倍10倍になったときに
残りの79%の生産性って5倍10倍にできますかって言ったら
まあまあ大変ですよねという話です
なのでどんどんどんどん
まあ何でしょうね
プログラミングは特に好きな人であるほど
なんか僕ガンプラ作りたいのに
なんかガンプラ作りマシーンが出てきちゃったみたいな感じになっちゃってて
ガンプラ作る以外の仕事の方が多くなっちゃってるみたいな
まあそんな感じになってる
まあAIのパワー
まあベンおじさんもこう言ってますけども
AIのパワーを使いこなすっていうことは
それに伴って
まあレビューだったりセキュリティだったりとか
そういういろんな責任っていうものが
そっちの方がどんどんでかくなっていきますよ
っていう話でベンおじさんが言ってます
これ数字で見ると
AIが書いたコードの半分ぐらいには
脆弱性が含まれてますよとかね
で開発者がそのAIが吐き出されたコードに
自信持ってますかって言ったら
自信持ってる人が29%しかいないとか
あとはプラットフォーム管理者とか
セキュリティの管理者
セキュリティのリーダーからすると
もう92%ぐらいの人は
もうあいつらどんなAI使ってるのか分かんないと
あいつらが上げてきた
コミットしてきたコードってどうやって作ってるのか
まあAI使ってるんだろうけども
何使ってるのか分かんない
そんな話になってきて
それがセキュリティリスクにも回ってると
でじゃあこうならないために
何しなきゃいけないかっていうところが
ここからの本題になります
AIが量産するコードにどう立ち向かうか
っていう話なんですけども
人間とAIがコーディングっていう分野で
勝負をしたとしても
まあもはや人間には絶対勝てないですよね
量も勝てないスピードも勝てない
じゃあ質はどうかっていうと
まあAIまあまあクソコード書きますっていう話しましたけども
まあ人間だって大概ミスりますよね
要するにAIの方がめちゃめちゃ量が多くて
なんかバンバンバンバンすごいスピードでコード生成するから
まあミスの量も増えてるけれども
じゃあ人間がミスらないかって言ったらそんなこともない
ちなみに生成AIってまだ3歳児なんで今が一番弱いんですね
これからどんどん強くなります
で体力で言うと24時間働きますかって言ったら
人間24時間働けないですよね
なのでこれ英語のことわざで
火には火を持って戦えと
まあ相手と同じ手段を持って
迎え撃とうという話で
これAIに対抗するにはもうAI使うしかないですよと
まあ今日のセッションの中でも結構AI使って
構造レビューしてますよとか
まあそういう話も出てきましたけども
その辺をちょっと整理したいと思います
これまずAI以前に
そもそもちゃんとしたパイプライン組んでますかっていう話ですね
まあAIが非常にやらかしがちなので
目立ってますけども
人間だってまあまあやらかしてますよねと
なのでガードレールっていうものはそもそも必要ですよね
でAIはちょっと人間と違って
自信満々にすごい迅速に激しくやらかすというところが
AIが人間と違うところで
あとAIは責任取らないですからね
ただ結局やってること人間と同じなんで
AI導入前からこういうことちゃんとやってますかって言ったら
まあそんなにねちゃんとできてないと思うんですよ
例えば堅牢なパイプラインを組むっていう意味で
ちゃんとパイプラインの中でシフトレフトを実装していきましょうと
コードコミットしたらそこでもうすぐにSASTが走るとか
まあリントが走るとかもそうですけども
あとは依存性
ライブラリの依存性をちゃんとスキャンするだったりとか
シークレット
例えばそのパスワードがベタ書きされたりとか
まあそういうのないですよねとか
そういう自動的にスキャンできるものは
ちゃんとパイプラインの中に
パイプラインのタスクとして組み込んでいきましょうと
これはそもそもAI以前からそういうことはGitLabは言ってますと
でこのパイプラインポリシーが
1個のレポジトリだけで動いてるんじゃダメで
もう組織として全部の組織が
そのパイプラインポリシーをちゃんと適用してるかっていうところを
まあガバナンスっていうんですかね
まあ強制していかなきゃダメですよと
まあこれはそもそもAI以前からなんだけども
AIが出てきてこれがより重要になってきたっていう話ですね
で次AIのコードレビューです
あのまあ人間がレビューできる量じゃなくなってきてるんで
もう人間がレビューする前に
もうAIにレビューしてもらいましょうと
でじゃあAIのレビューツールって何があるって
黒族に聞いたらあろうことが一番上にGitHubって書き上がって
えーっとですね
まあコパイロット4PRありますよね
はいまあこれまあすぐGitHub使ってれば
まあコパイロット使ってればすぐ使えます
まあこれ便利ですよねと
まあCodeRabbitとかそういうね
AIレビューの専用のツールとかも出てきていたりとか
まあAmazonのCodeGlue
まあこれはどっちかちょっと機械学習ベースですかね
でまああのレビューしてくれるとか
あとはあれですね普通のLLM
あのクロードオパスとかソネットとか
ああいうなんか強力なLLM使えば
そこに変更されたコード投げて
これレビューしてって言えば
ちゃんとレビューしてくれるんで
それはAPI使って
まあそういうちょっとしたツールを作る
っていうのもありかなと思います
でここで
例えばコーディング規約とか
そういうものも一緒に渡してあげて
このコーディング規約に沿ってるか
まあそれもそういう観点も含めてレビューしてみたいなことは
まあ自作ならではで色々カスタマイズができるかなと思います
ちなみに
Gitlabどうなってるかっていうと
これちょっと細かくて見えないかもしれないですけども
この右側
レビューは一人のレビューはっていうところに
Gitlab Duoっていう
まあたぬきマークがいるんですね
こいつAIです
なので
マージリクエスト投げるときに
マージリクエストってわかりますかね
あのGitHub流に言うとプロリクエストなんですけど
Gitlab流に言うとマージリクエスト
マージリクエスト投げるときに
まあレビューアーとして
もうこいつAIをもうアサインしちゃいますと
そうするとコミット積んだ時点で
もう勝手にレビューしてくれます
で
まあちょっとこれ英語でレビュー返ってきてますけども
まあ日本語でよろと言えば日本語で答えてくれる
まあこういうものがもうGitlabなんかは最初から入ってるんで
まあこういう機能をどんどん使っていくと
というところですね
あと
最終的には人間がアサインされなきゃいけない
まあ本当にね最後にマージする前には
人間がちゃんとレビュー
まあAIのレビューコメントを参考に
どこがどういうふうに修正されたかっていうのも判断して
人間がマージ
承認してマージしなきゃいけないんですけども
じゃあ人間のレビューは誰をアサインするっていうところも
このGitlab流くんがおすすめしてくれます
このフレームワークでこの言語で書かれてるんだったら
この人にレビューしてもらうといいよみたいな
そんなのも推薦してくれたりする
まあそんな機能がプラットフォームに備わっていったりする
あとできることもう一つとして
まあ脆弱性ね
さっきあのAIが書いたコードの半分ぐらいには
脆弱性含まれてますっていう話しましたけども
じゃあ脆弱性見つけるっていうところは
まあ普通にねセミグレップとかそういうので
見つけると思うんですけれども
それどうやって直すかっていうところって
まあここでAIの出番ですよねと
例えばトリビーのコンテナイメージスキャンで
CVE
まあこの右側にちょっとしたスクリプト書いてますけども
コンテナイメージスキャンで
CVEが見つかったら
それをちゃんとGPTに投げて
でどうやって直せばいいのって教えてもらって
でその後自動で
えっと
まあドッカーファイルを修正する
プルリクなり
マージリクエストなり
まあそういうものを作成してもらうとか
まあそういうワークフローも
可能かなと思います
であと今時のセキュリティスキャンツール
えっと
スニークとかユーサーズのやつとか
まあだいたい後ろにAIいるんですよね
でAIがどうやって直せばいいですよって
サジェストしてくれるので
まあそれ利用するっていうのも
まあいいんじゃないかなと思います
ちなみにGitLab
GitLabこれ左
これも細かくて見えにくいかもしれないですけど
左側がこれ
えっとセキュリティスキャンの結果
見つかった脆弱性のダッシュボード
でこの脆弱性が見つかりました
これバッファーオーバーフローの
なんかかと思うんですけども
この右上にえっと
AIを使用して
解決するっていうのと
AIを使用して説明するっていうのを
選べるようになってます
でこの右側
えっとこのGitLab Duo Chatっていうやつがいて
でこれこの脆弱性どういう風になっていて
でどうすれば直せますよっていうのを
教えてくれたりする
まあこういうのが
これGitLabはこういう機能がありますと
まあこれに近いようなことを
まあ実装していけばいいんじゃないかな
っていう風に思います
でえっとちょっと暗くて見えないかな
コード生成するだけじゃなくて
AI活用すべきところっていうのはいっぱいあって
これあのGitLab流のパイプラインっていうか
ワークフローなんですけれども
えっとGitLab流は
まずエピックイシューやるべきこと
タスク課題が書かれますよね
まあそこのところは
AIに手伝ってもらいながら
人間が書くでもいいですし
人間が延々と議論してきた結果を
AIにさまってもらう
まあそういうやり方もあると思います
でそれがアサインされたら
GitLab流はまずマージリクエスト立てる
まあなんていうの
GitHub流っていうのかわからないけど
普通最後にプルリクじゃないですか
GitLabはもう最初にもうコミットする前から
マージリクエストなんですよ
マージリクエストがある状態で
そこにコミットを積んでいくと
でなんでそれがいいかっていうと
コミット積んだ段階で
先ほど言ったセキュリティスキャン
SASTだったりとか
そういうパイプラインが勝手に走るので
人間が待たなくていいっていうか
どんどんどんどん直していける
コミットの時点でどんどんどんどん直していける
っていうところですね
でこの緑の文字で書いてるところが
これ全部AI使えばいいじゃんっていうところなんですよ
なのでいろんなパイプラインのいろんなステージで
AIが使えます
例えばマージリクエストを作るっていうところに関しても
マージリクエストのサマリーをまとめた
マージリクエスト自体をAIに書かせたりとか
あとはもちろんコードを書くっていうところに関しては
コードサジェスションとか普通の機能を使えばいいんですけども
あとテストを生成する
テストケースをAIに作ってもらうだったりとか
テストが失敗したときに
テストがこけたルート構図をAIに教えてもらうだったりとか
あとはもちろん脆弱性のサマリーを出してもらうとか
脆弱性の解決案を出してもらうとか
あとレビューですね
レビューはもちろんやってもらう
ディスカッションのサマリーをAIにやってもらう
いろんなステージでAIが使っていきますよね
なのでコードを書くっていうところ以外
ちゃんとAI使っていきましょうねっていう話です
これを実装していく上で何が大事かっていうと
コンテキストなんですよ
これどういうことかっていうと
例えばコンテキストがない状態で
このコードを変更しました
このコードをレビューしてくださいってAIに言うと
このコードにバグがあるかもしれません
それが本当にバグなのか
何か意図した動きなのか
そのコードだけ見ていたら分かんないものって
結構ありますよね
でちゃんとそのプロジェクトの中の情報
例えばイシューだったりとか
前回のプルリクの情報だったりとか
デプロイした時のログだったりとか
そういうコンテキストがあって
しかも設計文書だったり
そういうものがちゃんとコンテキストとしてあれば
このコードはイシュー234の要件満たしてませんと
過去のプルリクで同様の実装があって
その時のレビューコメントと修正コミットと
デプロイ結果を参考にすると
こういうふうに直すべきです
こういう
何でしょうね
いいレビューをしてくれる
で要するにコンテキスト与えられないAIっていうのは
その日だけやってきたタイミングのバイトなんですよ
まあいかにプログラミング得意だとしても
もうプロジェクトの情報を知らないんで
このコードはここ見てここバグじゃないですか
まあそういうことはできるんだけども
コンテキスト与えられたAIっていうのは
もうプロジェクトメンバーですと
プロジェクトの情報全部知ってますと
そしてプログラミングもめっちゃ得意っていう
まあこの大きな違いがあります
なのでこれを使ってAIをちゃんと働かせましょうと
じゃあプロジェクトのコンテキストって何なんだっていう話なんですけども
例えば言えますかね
左側ドキュメント
もちろんリードミーとかもね
ちゃんとしたコンテキストですよね
あと仕様書APIの仕様書だったりとか
あとウィーキに何か仕様が書いてあったりとか
プロジェクトのドキュメント
それからもちろんエピックイシュー
この回収でどんな機能を実装しますとか
そこに至る議論の経緯だったりとか
そういうものですね
でもちろんコードベース
コードそのものっていうのはもちろん一番大事なコンテキストです
でその一つのファイルだけじゃなくて
そのレポジトリの中にある全てのコードがコンテキストになります
あとCICDのログですね
ビルドの履歴テストの結果デプロイメントの記録
そういったものをコンテキストになる
あとはチームとしてのコーディング規約
レビュー基準ベストプラクティス
こういったものもコンテキストになりますと
とはいえ全部の情報がLLMのコンテキスト頻度
LLMが受けられるコンテキストの量って限られているので
例えばここに例を挙げているのは
これGitLabでGitLab作ってますっていう話だったんですけど
GitLabっていうプロジェクトのレポジトリを見ると
イシューが63,700件
マージリクエスト2000件
コミットが484,233個とか
まあまあすごいことになっているんですよ
これをLLMに渡せるかって言ったら渡せないですよね
なのでこの中から
じゃあ今やりたいことに関連しているコンテキストっていうのを
どうやってLLMに食わしていくかというところが重要になってきます
はいというわけで
じゃあプラットフォームエンジニア何をしましょうかっていう話ですね
まずこれシステム的なところじゃなくて
人間の働き方みたいな話になってくるんですけども
ここも多分プラットフォームエンジニアリングとしては
意識していかなきゃいけないところです
ドキュメントをレポジトリに収める
これって今だから未だかつてなくこれが重要になってきている
例えばそのワードエクセルで書かれたとか
なんかPDFだったりとか
まあそんな人間だけが読める文章じゃなくて
ちゃんとAIにも読める形で
まあ例えばマークダウンとかね
そういう形で設計書、仕様書、開発標準
まあそういったものをちゃんとレポジトリの中に収めていきましょう
でまあ人間にも読める
AIにも読めるそういったフォーマットで残しましょう
ただ既存のプロジェクトでそんなのないよ
コードしかないよみたいなのもあると思うので
まあAIにコードから仕様書を書いてもらうっていうのも
十分現実的な使い方になってきています
で実際結構あの
私たちのお客さんとかかなりミッションクリティカルな
まあ例えばコボルのコードとかね
あの職人のなんか秘伝のタレみたいになっているやつから
ちゃんと仕様書を起こして
仕様書になることによってそこから
えっと
ジャパニーリファクターできるとか
まあそういう話もあったりするので
AIに仕様書を書かせるっていうのも現実的です
あとイシューをちゃんと書く
イシューっていうのは
まあなんでそういう仕様になったのかっていう
経緯がちゃんと履歴に残るので
それも非常に重要なコンテクストです
で結果だけじゃなくて
途中の議論も含めてちゃんとイシューに残しましょうと
でそのためにはそれを人間がやりやすくするためには
もうイシューテンプレートをきれいに整備してあげましょうと
まあこれもちょっとプラットフォームエンジニアリングなのか
開発チームなんかどっちが温度を取るべきか分からないですけど
まあイシューテンプレートが整備されていると
人間もそれがやりやすいと
で先ほどのマージリクエストから始めましょう
まあこれGitLab流ですけども
まあこれってAIと非常に相性のいいやり方だと思っているので
はいマージリクエストから始めましょう
まあこういうルールですね
でこういったコンテクストをできるだけ一箇所にまとめると
まあレポジトリでもいいんですけども
まあGitLabならGitLab自動の一個のプロジェクトの中
まあGitHubでもいいですよ
あの一個のプロジェクトの中に一箇所にまとめておきましょうと
でここが
悩ましいところで
じゃあ大量のコンテキスト情報から
LLMに効率的に食わせてやるために
何ができるかっていうと
まあ一つのやり方は
MCPとラグを使う
っていうやり方はあるんですけども
ただこれって情報がバラバラに存在していると
かなり高コスト
要するにラグ自体がGPUをぶん回すんで
まあ結構コストはかかる
でナレッジグラフっていうやり方もあります
何だろう情報のインデックスをあらかじめ
そのグラフDBっていう形で関連性を
グラフDBに持たせてあげて
それをプロジェクトの中で持っておく
でこれはGitLabは
実際このグラフDB
ナレッジグラフっていうものを
実装を進めていますと
これオープンソースで公開されているので
何なら
僕のMacのローカルとかで
シュッと動くんですよ
もう本当に結構なプロジェクトだと
もう1秒ぐらいでこのインデックスが
バーッと作られて
でこのコードはこの構造と関係があるよ
みたいなのが
こういうグラフツリーみたいなもので
見える
まあこういうものを使って
GitLabは
LLMに今やろうとしているタスクに
関連する情報を渡してあげる
ということをやってます
はい
ちょっと興味ある方がいたら
覗いてみていただければと思います
で
ここでようやく
AIエージェントですね
AIエージェントの例は
例えばイシューをサマライズして
構造への影響と作業量を見積もるとか
イシューからマージリクエストを作るとか
構造レビューする
テストの失敗原因を分析
要するに人間がやりたいことを
どんどんエージェントにやってもらう
これ自体は結局後ろのLLMに
情報を渡して答えをもらうというのが
エージェントの仕事になるので
LLM次第というところもあります
で
LLM何使うか問題ありますよね
結局
組織としてというか会社として
何でもかんでも
クラウドのLLM使っていいってことは
まあまあないと思うので
あとコストとセキュリティと
あとこの
このAI会社大丈夫かみたいな
そういう超えなきゃいけない壁もあると思っていて
ちなみにGitLabの場合は
エージェントプラットフォームというのがあって
この下の統合データモデルというところは
要するにコンテキストストア
プロジェクトとはコンテキストストアですよね
という考え方です
でその上にいろんなエージェントが動きますと
さっき例に挙げたような
いろんなエージェントが動きますと
あとコーディングエージェント
上の
例えばクロードコードだったりとか
ウィンドサーフだったりとか
コーディングエージェントは
それはもう開発者の手元で使うものなので
それは好きに使ってくださいと
でそれがMCP経由で
このシングルデータソースみたいなところから
情報を引っ張ってこれて
連携できるっていう考え方が
GitLab Duoのエージェントプラットフォーム
っていうものになってます
あとクラウドのLLMってクソ高いですよね
これね
あたりGitLabの社員って
アンストロピックのAPI使えるんで
技術系の社員を使っていいことになっていて
で何も考えずに
デモアプリとか作るのに使ってたんですけども
これ8月のお値段557ドル
やばくないか8万円ぐらい1ヶ月で
僕1人で
これ会社にバレると怒られるかもしれないですけど
これがね僕1人だったらいいけども
100人1000人1万人でなってくると
もう自前でLLMクラウドを作った方がいいんじゃないか
っていう話ですよね
でGitLabはちなみにオンプレの
ローカルLLM使えるんですよバックエネル
VLLMとかそういうものを使って立てればいいんで
そこは何でしょう
コストとかセキュリティとかそういうところで判断することになると思うんですけども
プラットフォームの機能先ほどのエージェントが動くデータストアをちゃんと扱えるっていうところが
LLMが何かに依存しないっていうところが大事かなと思います
はい時間ないのでまとめです
統合されたデータが大事ですよ
あとAIフレンドリーなAPIが大事ですよ
拡張可能なアーキテクチャが大事ですよ
であとUIですね
これ結局人間がじゃあAIエージェントに何させるかって言ったら
なんだかんだチャットが使いやすいんで
先ほどGitLabの画面でもお見せしましたけど
ああいうチャットみたいなUIがあると使いやすいでしょうね
ですね
はいAIがコード書きすぎ問題はもう今そこにある機器ですと
でボトルネックはコーディングじゃなくなってますよと
AIをちゃんと使って対抗しましょうよと
で実装方針
コンテクストの整備が一番大事ですっていうところがお伝えしたかったところです
でそこからじゃあどこに開発側のボトルネックがあるのかっていうところは
その開発チームとちゃんとヒアリングして
じゃあそれを一個一個AIエージェントで解決していくっていうアプローチがいいんじゃないかなと思います
はい
ご質問受け付けます
はい
発表ありがとうございました
それでは質疑応答の方を進めさせていただこうと思います
一つ目ですね
ビルド履歴やテスト結果のコンテキストはどのような目的で使えますか
全然入れようと思ったことがありませんでした
とのことです
こちらよろしくお願いします
ビルド履歴
テストが動けてたら何か間違ってるってことですよね
で何か間違っていて
でじゃあ次回それを修正しました
で
例えば
違う
違うバージリクエスト
違うイシューに対して違うバージリクエストを上げていて
でコードレビューの時に
あの時こういうコードを書いたら
こういう失敗をしていました
だからこのコードは直すべきですっていうところを
テストに行く前に
AIのレビューバーが教えてくれるだったりとか
あとは
そうですね
ビルド履歴ですね
まあビルドも結構
あの
何回もやってると結構時間かかっちゃったりするので
もうビルドする前に直せるものは直しちゃうとか
まあそういうことができるかなと思います
で実際今ってどのようなLLMツール
次いいですか
はい
実際今ってどのようなLLMツール組み合わせをしてますか
これは私はGitLabの社員なので
GitLabはLLMとしては
基本的にはアンソロピックの
クロードオーパスとかソネットとか
あの辺を
GitLabのプラットフォームが勝手に選んでくれる
でツールは
もう私はほぼGitLab
ただクロードコードも使うんで
実際コード書いたりするときは
クロードコードを
クロードのAPIを叩いて
使ったりしてます
はい
はいありがとうございます
時間もちょうど良さそうなので
こちらで質疑応答の方を
終了させていただこうと思います
はい改めて発表ありがとうございました
ありがとうございました