#1 Lintはメンタルに効く！？ - podcast episode cover

#1 Lintはメンタルに効く！？

くわラジ
Apr 17, 2026•38 min•Season 1Ep. 1
--:--
--:--
Listen in podcast apps:
Apple Podcasts
Spotify
Download
YouTube
Overcast
Pocket Casts
Episodes.fm
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Summary

Lintが「メンタルに効く」という意外な視点から、開発者の自信向上に果たす役割を深掘りします。Lintの起源である「糸くず」の意味から、スタイルチェックだけでなくセキュリティやバグ検出まで多岐にわたる機能、言語仕様との関係、そして将来的なAIやフレームワークへの統合までを網羅。コード以外の仕様書などへの応用事例や、AI活用における課題と解決策についても詳しく解説し、品質保証と開発効率を高めるLintの可能性を探ります。

Episode description

「Lintはメンタルに効きます！」


適当なコードを書くと絶対に怒ってくるあの「Lint」について、kuniwakに聞いてみました。すると意外な答えが！？


「Lint」が何者で、どんな目的があるのかわからない人は必聴です。チームに「Lint」を導入するときの目的がはっきりとわかるようになると思います。

Transcript

⁠ Lintへの疑問とメンタル効果

C

国分けさんちょっと聞いてほしいんですけど普段コードを書いていてプルリクトが出した時にリントが原因でCIがエラーで落ちてますみたいな 感じのことが結構あってまたリントガーみたいなことが結構あるんですけど実はですねリントガー何者でなんであんなに細かく起こってくるのかっていうのは正直よく分かってないんですよね リントに指摘された項目もちろん直していくんですけどこれはやり方としては脳死で修正していくみたいな感じになっててこれ本当に生産的なことなんかなとか思ったりとか リントって本当に意味あるんですかね何の意味があるんですか

B

とてもよくわかりますねとてもよくわかるんだけどそうですね私から言えるとしたら実はリントってメンタルに効くんですよ

C

メンタルに効く全然思いも寄らなかったような角度からの回答なんですけどどういうことですかね

B

私が日々いろんな開発者を見ていて思うのはみんなちょっと自信がないんですよね自分の設計だったりだとかコードとかにいつでもこうちょっと自信がなくて だから何かこう自信を与えてくれるものを常に探している例えばテストだったりあるいはリントだったりのような それを入れることで自分が一定以上の品質の行動を強制されているかけてるんだっていうことがわかるようになってそれがメンタルに効くということなんですよね

C

じゃあどちらかというとチームのためというよりかは自分のための方が大きいんじゃないかということがレイントを使うの

B

導入の動機は間違いなくそれだと思います例えば実際に誰かが技術を導入するという時にチームのためっていう風に入れる人ももちろんいると思うんですけどやっぱり最初っていうのは自分がちょっと便利になりそうだからっていう時の人が多いと思うんですよ そういう風に入った時にはやっぱり一定以上の品質のものを書きたいっていう願いっていうのかななんて願望があってそれをやっぱり一定解消してくれるっていうのがリントなんだろう

C

なるほどじゃあやっぱり自分が使いたいから自分の生産性を上げるためにLintっていうのをチームで導入していってその中でいい行動というか 強制された上でそのリントによって強制されたコードがこれであれば最低品質は保たれているであろうというお墨付きをもらいたいから使っているというところがまずあると

B

本当にその通りだと思いますそれはいくつものことから見て取れて例えばイエスリントとかって呼ばれているJavaScriptのリントには膨大な量のルールが あるわけですね一つ一つをちゃんと選んでいくとチームに合った形でのコードっていうのを強制することができるんだけれども実は皆さん一個一個ルール有効化してたりしないですよね皆さんだいたいAirbnbとかのプリセットを使って 使ってなぜじゃあそのプリセットを使うのか一個一個カスタマイズした方がチームに合ってるものを作れるっていうのは当然のことなわけですよだけどそのプリセットを使ってこと自身が私は自信の朝の現れだと思っています 他の人に決めてほしいんですよ

C

そっちの方が楽だから

B

自分でそこを考えなくていいと一定の品質は担保されると思うっていうところから私はその 人々はリントっていうのをメンタルのために結構使ってるんだろうと思っている

⁠ Lintの多様な機能と語源

C

なるほどちなみにUSリントだったらルールの数どのくらいあるか知ってます

B

いやもうとんでもない数がありますねあれスタイルのリントもあるしいろんなリントもあるのであとはプラグインとかも含めたら本当にとんでもない量のリントがあるはずですね

C

じゃあ100とか200とか聞かずにもう1000くらいある

B

1000はないんじゃないかな だからこういう時はちょっと本当にわかんないそう野良ルールとかも含めれば線とかはあってもおかしくないかもしれないですね

C

だいたいクリアケさんが今までの見ていくプロジェクトでいろんなリントとか見てきてくるかなと思うんですけどその中でルールがイメーブルされている レールがどのぐらいありましたか?なんとなくの肌噛んでいいですか?

B

他の人がメンテしてるところだとやっぱ20とか30とかイレベルされてるものが多かったですねゲームのガンスとかもそんな感じだったかなCシャフトゲームとかだと

C

やはり全てを有効化しておくというよりかは本当に重要な部分だけ有効化しているリントのリュールで

B

本当はそれが一番いいんですけどでもやっぱり何の目的で使うかということによってその設定の目的って変わってくると思っていてメンタルに効かせたいんだったら標準的なもの長いものに巻かれろっていうのはすごく効くと思います ただ例えばリントの中にはセキュリティ警告を出すようなリントも結構あって例えばパールのリントパールクリティックっていうリントがあってこいつは危ないタイプでのセキュリティのこう 脆弱性を作り込んじゃうような関数の呼び出し方とかっていうのを指摘してくる機能があったりしますこれとかっていうのを例えばコードレビューとかでいちいちチェックしなきゃいけないのがめんどくさいからだから自動化しちゃおうとかっていう風な使い方とか

C

なるほどただの文法だけじゃなくてセキュリティ医者になりそうだよといういわゆる経験則的なコードの匂いみたいなバグの匂いみたいなところまでリントは サポートしている範囲としてある

B

その通りです。ここからちょっと少しリントの定義というか、成り立ちとかの話に少し近づいてくるんですけど、リントっていう名前、そもそもこのリントって名前不思議だと思いませんか? リントっていうのはもともと糸くずっていう意味で本当は糸くずだから取りたい糸くずを取るためのツールのことをリントと呼んでいた

C

細かいゴミということ

B

元々はC言語で1978年頃に登場したのがこのリントというものになっていて 大昔なんだけれどもこのリミットの役割っていうのは当時からやっぱり スタイルのチェックだとかそういうところとかやっててここに私はちょっと名前の名があると思っていてすっごく重大な問題をめちゃくちゃ頑張って発見するっていうツールじゃないんですよ リントって糸くずってそんな重大なものじゃなくてなんかこうちょっとうざったいな取りたいなみたいなそのレベルのものそれを取るっていうのがリントっていう風な名前になっていてなので今大昔の1978年のリントから今に至るまで リントって呼ばれてるものはほとんどそういう風な結構軽量に検出できるものっていうものを主に扱っているっていう感じですね

C

基本的には機械的に簡単にパッと見れるところのところがルールが主

B

PHPスタンみたいなバケモンみたいなものもあればもっと簡単なものもいっぱいあってなのでLintはそのスタイルだけを調整するものかって言うとそうじゃなくてセキュリティー外国もそうだし あとはこれほぼバグるよみたいなものを指摘してきますね例えば未宣言変数の参照とかこれがほぼ確定的にバグるってやつでこれからなんかも指摘してくるのでバグの気配だったり セキュリティのものだったりあとはスタイルのものだったりいろいろ軽く見つけられるものすべてを大体見つけるっていうのがLintの定義と言える

⁠ 言語仕様とLintの役割変化

C

基本はリントの基本はそういった軽いところでその応用編としてリントで一緒に実行してしまってるんだから セキュリティのイシューとかも一緒に警告出そうよねみたいなのが応用的な使い方

B

Oh yeah.

C

そして発展していったっていうのが現代のリンク っていう成り立ち確かにそう見ると納得感がありますね じゃあ本当にリントがなかった頃というか別に現代でもリントを使ってないプロジェクトっていっぱいあるかな 思ってて現実的にはそういったところでも 別に問題になるというよりかはやはりそういうゴミみたいな本当に糸くずみたいなところを取ってきれいにしていくというところがリンタの役割としてはまる

B

ここに私はちょっと面白い経験則があると思っていてリントを全く入れていないプロジェクト結構言語によって偏りがあると思います 例えばJavaScriptはYesLintみたいなのを入れる人がほとんどでしょうねパールもパルクリティックみたいなLintを入れる人は結構多いんじゃないかなと なんですけど例えばラストにリンと入れます そう言っているのがあってここに私はちょっと思うところが結構ありますっていうのはコンパイラーもこのコード確実に壊れてますみたいなときにエラー出しますよね リントンを出しますよね

C

同じこと言ってるぞ

B

かぶっててなのでコンパイラーとかがインタープリッターが優秀であれば優秀であるほどリントがしょぼくなるんですよ

C

さっきの話聞いてて行動の確実にバグりますよみたいなところだったりあとはこういう書き方だとちょっとおかしいよねみたいな言うのってそもそも言語仕様として やってしまった方が良くないと思ってて取り入れちゃった方が良くないそんなところみたいなことを思っててそれがまさに店が言ってもらったコンパイラーだったりとかそういう警告の 実際に実行するときの警告文みたいなところが賢くなってたら林道はちょっと素朴になっていくみたいなところと

B

本当にその通りです例えばわかりやすいのはPythonってインデントが意味を持っている言語になっていてインデントがちゃんとしてないと動かないんですよあの言語 ということはこれはインデントをチェックするようなリントがないってことなんですね アイソン側がインタープリンターがチェックしてくれてるからでハスケルとかもこういう風なオフサイドルールって呼ばれてるようなそのインデントのルールっていうのが結構備わっていてなのでこういうものはコンパイラー側がスタイルまで口を出してくるっていう

D

Hm.

C

言語によってかなり違う

B

言語によってかなり違うJavaScriptはすごく自由だから本当にいろいろみんながガチガチでコミュニティのルールも分裂してたりするぐらいいろいろあって セミクロンつけるつけないとか そう、JavaScriptでよくLintのルール揉めますけど

C

なんかJavaScriptとかの場合はLintとかでAutoFixというか簡単にかけ替えるやつとかあるかなと思うんですけどそういったところが若干言語仕様のところまで踏み込んでるかなみたいな感じなんですかね

B

そうですね オートフィックスは基本的にこうあるべきだろうっていうものへの差分を計算できるときとしかオートフィックスできないんですよこうあるべきっていうのが姿が一つに定まるべきじゃないといけなくて 姿が定まってなくてもできるのが今のAIとか生成AIとか使ってるタイプのやつとかであれはなんとなくいい感じで埋めてくれるわけだけれどもその代わり重くなっちゃうんですよね だから今のリントっていうのは軽く特に毎回保存時とかあるいはちょっと書き換えた時に毎回毎回実行されても遅くならないぐらい高速なことしかしないっていう風に割り切りがあるのでそういう風な

C

じゃあ今AIみたいなLLMとかを使ってそういうコードフォーマットないしは勝手に書き換えるみたいなことをやっているのは本質的にはもしかしたらLintという呼ばれるものではなさそう

B

あんまりニットと呼ばれるものではないですね

⁠ Lintの未来とフレームワーク統合

C

なるほどじゃあ逆にこれからのリントってどうなってくるんですかね

B

それはとてもいい質問で私がリントですごく予測していたのは歴史からだまん話していこうかなと思いますまず最初に登場したリントっていうのは 検査ルールと検査対象のデータを巡回していくっていうブログラムが一緒くたになっている統合型みたいな感じのリントになっていてこれは 作るのは結構最初の頃は簡単で手早く作れるんだけれどもだんだんとルールが増えてきたりだとかあるある人はこのルールを 作ってくれたので取り込みたいとかっていう時にいちいちコードのメインラインに入れていくっていうのはめんどくさいっていうのがあってプラグイン形式みたいなのをやりたいっていう時にすごく不便な

なのでルールを一つ一つのコンポーネントとしてプラガブルにするっていうその概念が誕生してこれが分離型のリントっていうのが出てきたんですねこの分離型のリントが出てきたのはおそらく2001年頃 になっていて、JavaのスタイルチェックかあるいはPythonのPyLintこのあたりがルール分離型の初めてのLintになってくる この辺りになってくるとルールをいろいろコミュニティが足していくっていうようなことができるようになってくるこれは実は一つの可能性を生んでいてリントって言語ごとに大抵用意されていたんですけどみんな言語の上にフレームワークとか使ったりします そうするとフレームワークのルールを入れたくなってくる

C

また役とのコンポーネント

B

リアクトのコンポーネントのこれ使うなみたいなとかこれをリアクトを使ってない人に共生するのは変な話だからルールを切り替えられるようにしたいっていう そうすると一つのリントに色々なものが入れられるとこういうフレームワークのリントっていうのが可能になってくるわけですよ今はそんなに数が多くないんだけどフレームワークのリントってやっぱりあります こういうのがだんだん増えてきてだんだん今ってSSIによって生産力が爆上がりしてるからこのフレームワークはこういう風な使い方をしないでほしいっていうベストプラクティスみたいなのが今までドキュメントで配布されていたのがどんどんどんどんリントに変わってくる そういう風なのがまず短期的にフレームワークとか言語よりももうちょっと細かい単位で 入れたり外したりしたくなるようなものっていうのが増えてくるだろうと予測しています

C

それで言うとどんどんリントっていうのが本当に細かいところまで本当の意味での糸くずみたいなというところまで手が届くようになって という感じの予測だったんですけど逆にリントがいらなくなっていくみたいな世界線もあったりするんですけどさっき言った言語の仕様に取り込まれていく方向性 開発がどんどん高速化していくとだんだん言語仕様の方も高速化してくると思うんですよね言語の開発もっていう世界でもあったりする

B

これは私はおそらくそうはならないだろうと思っていて正確に言うとなる分野もあればならない分野もある2つに分かれるだろうという予測をしています なぜかというとまず分かれない分野っていうのはパイソンが例えばインデントに口を出し始めたようにもうガッチガチに縛っちゃって一つのある処理の意味に対して一つの行動しか許さないみたいな そういうふうな一つのやり方一つの書き方だけみたいなそういうふうな考え方の言語コミュニティっていうのが出てきた場合はこれはLintはほぼなくなるだろうと思います結構語言語とかがそれに近い

雰囲気を感じますね一方でいろんな書き方一つのやりたいこといろんな書き方っていう言語もまたあります例えばRubyとかがそれに代表されるものでこういうものたちっていうのは そこに芸術性っていうのかなとかいろいろなものを感じていて言語がそこを縛ろうっていう思想を持ってないんですよねだけどこの上に例えば何か大きな巨大な城みたいなものを建てようとするとある程度やっぱり秩序が必要でそういう時に輪刀を扱いたくなる っていうのがあってやっぱり言語側に吸収されているインタープリターコンパイラーに吸収されていくものとそうじゃなくてコミュニティが 自分たちがあくまで自由なところの上に自分たちの城を建てたいみたいな時に補助的に使うリントを使う世界ってこの2つに分かれていくだろうという風に予想

C

なるほどじゃあどっちかというとリント単体というよりかもしかしたらフレームワーク単位でリントが作成される可能性もなきにしもあらず

B

はいその通りだと思ってますね

C

レイルズのリント

B

今はルボコップの中にレイリーズっぽいものとかいろいろ入れたりできるんでそういうことは今はルボコップが受け止めてますけどただ例えばそうですね 例えばJavaScriptってJavaScriptにコンパイルされる言語たちトラスパイルされる言語たち っていうのがあってそういう言語たちってもともとのDSLintとかで検査しても大抵何もわからないわけですよそういうものたちっていうのはある意味フレームワークのLintに近いような形になっていてトランスファイル言語のLintですね そういうものとかっていうのも結構出てくるんじゃないかなっても下火にもなってくるんじゃないかなってもそうしています

⁠ コード外へのLint適用と運用課題

C

タイプスクリプトとかの場合はタイプスクリプトコンパイラーTSCとかが若干リントを見ているかやっぱりそこでやっているのかなというのが若干ありそうですけどね

B

そうですね タイプスクリプトはTSLintっていう有名なLintがあるんですけどあいつあんまりルールないんですよねそれなんでタイプスクリプトコンパイラーが大体やってくれるかっていう

C

なるほどやっぱり言語主要というかそういうところにリントは根差してるってことがありそうですね ちなみにそういうリントって今までの話だったらプログラミング言語だけだったかなと思うんですけどここからはもうちょっと広がってリントって先ほど言ったみたいな感じで糸くずを取っていくみたいなツール だったんですけど自然言語だったりとか仕様書みたいなところまでLintの適応範囲ってどんどん広がっていくんですかねプログラミング言語以外のところでも

B

それはとってもその通りだと思っていてまず一番最初にリントは自然言語に行く前に設定ファイルとかのリントにまず行きますね例えばテラフォームみたいなのとかプログラムというかどっちかというと設定ファイルに近いものだと思うんですけどテラフォームではリントは あれはその設定ファイルに対してこういう書き方を調整するってまさしくコードの延長線上でやっているっていうものなわけですよねこういうものたちがまず結構すでにいっぱい使われているっていうのがあると思います あとちょっと面白いものと代わりじゃないとGitに対するリントみたいなのがあってコミットメッセージに対するリントみたいな

言語に近づくなってくるんだけどGitにはコンベンショナルコミットっていうやり方があって頭にこれはこういうタイプの変更だよみたいなことをくっつけるみたいなのがあってそれが超過されてないものとかだと怒るみたいな感じのLintとかっていうのを作りたかった人がいるみたいですね とかがあったりします 先ほど使用書って話があったので使用書に関するリントは実は私が前職で作っていてDNA時代に作っていて画面使用書ってそのiOSのアプリとかAndroidのアプリがあってそのアプリの使用書に対する簡易的なリントみたいなのを作って これはAIを使ってなくて、例えばなんですけど、アプリの画面に画像を表示すると

ここに画像表示してくださいって書くときに画像が固定の画像だったら特に何も考えなくていいんだけれどもお客様の上げた画像とかだったりする場合ってその縦横の 比率とかって決まってないですよねそうなった逆に画面上でどういう風に拡大縮小するかアスペクト比を保つべきなのかという風な指定が必要になってきますこの指定を忘れると仕様が埋もれているということになってしまう ことになるのでこういうふうなのを画像をここにはめるんだとしたら少なくとも拡大縮小とかスペクト比を保ってとかっていうような文言が入ってなんてダメだよねっていうリントを作りました

C

なるほどじゃあ本当にルールベースですね 完全なるこういう文言を入れるべきであるみたいなルールがそこに定義されていて実行するとそれで起こってくれる

B

I'll go this.

C

どちらかというとデザイナーの指定 漏れを検出して エンジニアチームに渡す前に検出できるようにするみたいな使い方

B

What's up?

D

Thank you.

C

結構それワークしました

B

実際バグは結構例えば私の担当文からはかなりのバグを見つけてくれたんですよね本当に書かなきゃいけなかったのに書いてなかったところを見つけてくれたんですけど一方で運用は続きませんでした なぜかというとエンジニアが仕様書を書いていた時代があってその時はうまく回ってたんですエンジニアの使い方とかもよくわかっているから なんですけどだんだんエンジニアはちゃんとコード書く役割にシフトしていこうと仕様が出来上がったんだからコード書いてもって今まで仕様を書いてたエンジニアじゃない人たちがそれを触るようになってきた時にリントを気にしないでやっぱりやっちゃう

C

なるほど

B

当時そのリントやってる大使はコンフルエンス上にあったのでコンフルエンスってコミットするときにリントが必ず来るみたいな設定絶対できないですからそうなっちゃうともうやっぱり

C

実行が毎度されなくなったから境外化してしまったと 難しいですねその問題はとても あれですよね、だからそういう仕様書をGitHubとかで管理していたら毎回ちゃんとレートが実行されて確認できていたけどもビジネス職の方とかが差はあるからちょっと GitHubとかは結構難しいよねみたいな背景もあったって感じですか?

⁠ LLMとLintの実装基盤

それめちゃくちゃ難しくてどう解決すればいいのかって感じですね

B

そこに実は私は最近やっぱりLLMが効くんじゃないかなと思っていて そのルールをオートフィックスしてくれればいいわけですよルールに沿うようになのでLLMがオートフィックス勝手にしてくれるみたいな世界線はある意味運用が続くほぼ一つだろうとは思ってしまう

C

一回投げ込んでHuman in the loopみたいな感じで 例えば画面の比率とかだったら絶対こんな感じですかみたいなタッチでAIが聞いてくれてディレクターとかがそれですみたいな感じで承認していくみたいなそういうワークフローがちゃんと組めたら まあいいだろうというかちゃんとレイントを通すワークフローとしてワークするだろうみたいな形です

B

Yes.

C

なんかもう本当にリントって言えばリントだけどもワークフローの話ですよね

B

Come back from classes. Mm-hmm.

C

仕事の進め方というかやり方みたいなもうちょっとでかい話な気がしますねリントの是非というよりかは どう自由で進めるか

B

でもそういうふうな手段の中例えば単体テストとかいろんなテストとかそういうふうな問題を見つけるための手段がたくさんあってその中でもリントっていうのは比較的あんまりワークフローに影響を与えない方ではあります なぜかというと単体テストとかっていうのは先にテスト書くかとかちゃんとテスト対象がテスト用意になってないといけないねとかいろいろ考えなきゃいけないことがあるんだけれどピントっていうのは大抵そうではない っていうのがあって、インストールするだけでまぁまぁだいたい動くっていうのがLintのいいところで、場合によってはLint入れたら4000個くらいのケースになることももちろんあるんだけど そうじゃない限りは基本的にはインストールするだけで動くっていうのはいいところですね

C

その健全を健全なことを維持するっていうのがなかなか難しいってことですよね普通に それは多分普通のプログラミング言語にリントを入れて後から入れたパターンですねプロジェクトにめちゃくちゃ警告あるからこれいいよねみたいな感じでみんなでするするみたいなのとかなり似てる構造上の

D

Thank you.

C

いや、なかなか すごいですねやっぱそういうでもリントの進化先としてはやっぱりそういう人間のもうちょっと広いところの とともにそういうリントという考え方を適用していくっていうのは次の時代というかAI時代にとってかなり重要そうですよね ちなみにリントってどんな感じで実装とかってしていくんですかね例えばさっき例で開けてくれたその仕様のリントだったりとかってどんな感じで実装してたのか

B

Lintっていうのは基本的に大体2ステップから3ステップぐらいで実装されていて まずリントの対象となるものってのはコードって言うと文字列なわけですね使用書も文字列だしコードも文字列なのでただ文字列のままだとすごく扱いづらいんですよ正規表現でいちいち見つけるかって言われたら大抵の問題に使えられないので なのでまずは分析しやすい構造に変換するということをやります仕様書であれば例えば表があるんだったら表を抜き出してきてその二次元の個配列みたいなものを入れてあげるとかあとは例えばコードだと代表的なのが2つあって

一つはトークン列と呼ばれているものですね例えばJavaScriptとかで言うとファンクションほげとか書いたりするじゃないですかそうするとまずはファンクションっていう その一つの並びがあってその後にスペースが来てそこにホゲっていうのが来て次カッコが来てっていう風にこういう風にちょっとした単位に分割していくことができますねこれをトークンっていう風な言い方をしてこのトークンっていうのを の列ファンクションっていうのは次には空白が来て次に関数名が来て次に開きカッコが来てこれを検査していくっていうのがあります

これがトークン列をベースにするものもう一つは抽象項分離というものをベースにするものがあって例えばさっきのファンクションというのだと一旦そのファンクション全部が一つのオブジェクトになって このファンクションってところには名前と引数列とあとは処理の中身っていうのがこの3つが 個分としているわけですよねその個要素として持っていくと例えば処理の中にはさらに関数を生やすことができるわけですから最期的にこうな構造になって要するに基構造になっているんですよねこういう風な抽象工分離というプログラムを データ構造として機としてこらえましたものっていうのをこの2つのいずれかに変換してから検査するものがほとんどです

C

なるほどじゃあ扱いやすくするというのが手前にあるという大前提ある そこに対してルールを適用していてルールの適用に関しては単純な異風文みたいな感じの

B

基本的にはトークン列の場合は簡単で先頭から順に見てるだけです順に見てて要するに4位置ですね4位置でやっていくっていう形になる関数だったりも4位置とかリリースの方が分かりやすいかな 中小高分岐も実はほぼトークン列みたいなものでなぜかというと大抵深さ優先探索するから ですね深さ衛生探索はあの要するに木があったらまずはその子をどんどんどんどんどんここまでこういってもうこれ以上子がいないよだったら今日だっていなかったら上に戻ってみたいなことをやっていくっていう こうやっていく処理方法ですけどこの不可性センターに入手しているんで結局木を一列に並べてるんですよ 一列に並べてそれで検査していくっていうようなことをやっていくこれはリントの世界だとよくトラバースっていう風な感想だった トラバースという言い方をしていてだいたいどのリントにもこのトラバースというものが入っています中小小分岐を1列に並べて1個ずつ順番で見ていくという感じの処理をします

C

さっき言ってた使用書の 実装はどうしてたんですか正規表現的な感じになっちゃったのかなってなんとなくは思うんですけど

B

使用書の場合はコンフルエンスからデータを引っ張ってくるとJSONみたいな構造になってて表は表になってるし見出しは見出しになってるし本部は本部になってるっていう風にこの時点でデータ構造になってくれてるのでそこで表を見つけてきて それでそのJSONの中から表を見つけてきて そこだけを検査するみたいなそんなようなイメージです

⁠ AIベースLintの応用と課題解決

C

なるほど使用書の書き方自体もある一定のルールが存在しているそもそも それに倣ってプラスの忘れがちなところのルールを追加 リントって聞けば聞くほど応用範囲が広いリントというかリントの考え方みたいなお話かもしれないですけど高速に確認できる そういうターンラウンドタイムをできる限り小さくして確認していいもの、成果物品質を担保するみたいな考え方自体は本当にいろんなところで適応可能 なんかちなみに次こういうところに応用してみたいなってぐりわけさんあったりするんです

B

やっぱりちょっと遅くなるってことは前置きした上で生成によるリントっていうのをやってみたいなと思って実際今生成によるリントをちょっと作っていて今回の検査対象はテストケースです ベストケースっていうのは実際皆さんがソフトウェアを作った時にバグが入っちゃってるかもしれないわけですよねそれを検証フェーズに入るとテスターの人たちが この入力を試してバグがあるかなってことを確かめてバグが見つかればまずいってことがわかるしバグがなければその範囲では大丈夫そうだってことがわかるっていう活動ですよね このテストケースっていうのにはやっぱり良し悪しがあるんですよテストケースっていうのは入力と出力のペアになっていてこういう風なことをするとこういうことが起こるっていうのが書いてある例えば フィズバズ関数のテストケースだというと1の時には文字列で1が返ってきて3の時にはフィズが返ってきて5の時はバズが返ってきてみたいなそういう風なのがテストケースになっているわけですよねそういうテストケースが例えば悪いテストケースだと Aボタンを押すと正しい表示がされるとか 正しい行事とはってなる

C

ありがちですよね

B

ありがち。テストケースが本当は正しさのサンプルなので、あなたが正しいってことを使うと循環しちゃうんですよって話があって。 ダメなんですよね正しいって言葉をグレ性表現で抜き出してきて落とすってことは確かにできるんだけれどもそれをすり抜ける同じようなことをいっぱい書けるんですよね期待通りであるとか 観点表に書いてあるとかできちゃうわけですよそれは非常に良くないのでこれをやっぱり生成AIとかに食わせてみてちょっと高速じゃないんだけど要するにLintからちょっと外れてきてはしまうんだけれどもテストケースの問題を見つけたい やって結構いくつか成果があってこういう風なAIにその

静的検査機、レイントみたいなのを作ると、問題が2つあって、1つは遅い。これは週に1回回すとかっていうので、だいぶ軽減できるんですけど、もう1つは偽用性が多いことなんですね。 嘘の警告嘘ついてくるってのは2つの意味になっちゃうからどっちかというと誤警告が出てくるつまり警告なんだけど本当は実は警告じゃんそのモダ起こってないみたいなそういうことです何でもかんでも口うるさく言ってくるんですよおかんりんとみたいな これ実際私の手元であったやつだとある時は3分の2が合計国でしたね

C

多くかなり多いですねそれは

B

っていうのがあってまたあるケースでは100%がご警告でした

C

使い物にならない

B

この警告をいかに減らすかってことがそのAIベースの臨頭のポイントになってくるって感じですね

C

完全に 世の中がやっているハルシネーションを抑えるみたいなところがそこ

B

そうなってきます今回 やった方法は3つあります一つはネガティブプロンプトを入れる例えばこういうものはただこれはお客様にとってこれがOKかOKじゃないかってことが重要じゃなかったらそれは問題にしなくていいよっていうネガティブプロンプトを入れたり するというのはあります。これを入れるとだいたい100%だった互計獲率が60%ぐらいまで落ちてくれるんですね だいぶ落ちてくれるその代わり下人生って言って本当は指摘しなきゃいけないんだけど指摘を忘れちゃったみたいなのが もう一つの方法が敷地制御ってやつでAIに深刻度を何段階から評価させるんですよ深刻度これ以上のものだけは対応してそれ以下は対応しないかなとバッサリ切る 実際そのAIの判定した深刻度と人間の判断した深刻度を比べてみると大雑把に言うと相関がちゃんとあるっていう感じなんだけどもやっぱり何でもかんでも深刻と言いがちではあるんだけれども AIが深刻じゃないって言ったものはやっぱり人間は全部深刻じゃないって評価してるものだけしかなかったのでそのAIが最も深刻って言ったものだけを見ればいいってやると警告を15%減らせるんですね これもまた結構効く

これが2つ目の式地制御3つ目がこれがちょっと結構ユニークかなと思っていて形式化シンキングっていう方法を使いました

D

Yeah.

B

形式化シンティングっていうのはこれ私が普段やってることをちょっとAIにやらせてみたっていうやつの話なんですけど何か曖昧に書かれてるものっていうのは本当はどういうデータ構造を持っているべきで そのデータ構造に直した後にこういうふうな違反があるよってルールを検索させるんですよ ってことをやらせてみたらどうなるかという形式化シンキングってやつです今回の場合はテストケースっていうのはちょっと難しい理論を使ってテストケースはこういうデータ構造になるはずだよってことを伝えた上でそれに一旦せせやに変換させるんです

変換させてそれにこのデータ構造はこういうものが違反だよまずいものだよっていうのを与えてあげてそこでチェックさせるってことをやらせました そのチェックして出てきたものがデータ構造の言及する形になっちゃってるからちょっとわかりにくいので最後に噛み砕いて説明してね 人間には分かりやすい方がするっていうので結局人間はテストケースを入れて問題を受け取るっていう形に変わりはないんだけれども内側の質を変えるってことをやりましたこれをやったら利用成立が6割から3割も乗ってた そしてゲイン生率は3割だったものが0%になった ってのがあってこの結構形式化シンキングが効くんじゃないかっていうちょっと弱い証拠3プレスが少ないんで弱い証拠が得られたっていうことや

C

いろんなやり方でハルシネーションを抑えていくみたいなやり方もある一方でそもそものコンテキストとしてそのプロダクトがどういったもので何を重要視しているか みたいな大前提のコンテキストを入れておくことも結構重要だったりするんですかね

B

それは何を調べたいのかによるって感じですねこれもちょっとリントの考え方に少し似ていてリントっていろんなことをチェックすればするほどリッチにできるその代わり遅くなってくるんですよね AOも全く同じでコンテキストに追加してあげればあげるほど見られる問題が増えてくる例えば例えばあなたのテストケースはプロダクトのやりたいことを実現できてないみたいなことをやるためにコンテキストに ビジネス要件とか呼ばれるものとかみたいなそういうものを入れたからできなきゃいけないですよKPIとかお客様のペルソナコーデみたいなそれをやっていくと遅くなるしお金もかかる ここがトレードオフ

C

だからこそそこでちょっと線引きというかここまでは確実に検知できるからというところがりんとみがあるところ

⁠ まとめとエンディング

B

そこに痛みがあるところです

C

だからやりたいこととしては100%これによって品質が100%のテストケースが 担保されるよではなくてあくまでも最低品質が担保されている あのやりたいこと 確かにそれだったら一般的なテストケースだったらこういう感じになってるよねみたいな確かに聞きそうな感じがします すごい未来というかやっぱそういうところがあると本当に仕事とかでQAとかやるんですけどテストケースとか作るわけじゃないですかもちろん テストケースを作る専門家でもないわけですよ自分はこのテストケースが合ってるかどうかは分からないけどこのテストケースを流すことによって一定の安心感を得るからやるみたいな感じになってて まあでもそもそも大前提このテストケースが間違ってるとあれなんだけどもねみたいな感じで結構なりがちかなと思っててそういった意味でも本当に全く最初の結論と一緒でそれはもうメンタルに効くんですね

B

メンタルにつくんですよ

C

その最低保証がこのツールによってされてますよというのはかなりの安心度がありますね。

B

やっぱり私は開発する時に自信ってすごく大事だと思うんですよ 自信がないものを開発すると速度落ちるしやっぱり負の影響すごいんですよねだからなるべくなら自信を高めた状態で開発する方がやっぱりいい成果を生むと思っているのでその意味で私はリントがすごく役に立つと思っているって感じですね

C

いいですねなんかいい感じでちょっとじゃあまとまったところでちょっと今回はあの時間があるのではい心待てきしたいなと思いますなんかあのリントについてくねぎさん最後にあります言いたいこと

B

そうですね言いたいことはねやっぱりリントはね いいですよぜひ人と学んでいきましょう

C

リントはいいぞというところで ありがとうございますということで今回はここまでにしたいと思います ちょっとぬるっと始まったんですけどもっと詳しく教えてくださいラジオという番組ですこの番組ではですね略してクワラジって言ってるんですけどスーパーエンジニアである国分けさんに 今後もですねいろいろなこと聞いていきたいなと思います のでお客のプラットフォームで高評価や フォローの方ね またですねこんなことを国分けさんに かぼって聞いてみたいみたいなことありましたらコメントいただけると取り上げたいなと思う 方からつぶやいてもらっても大丈夫ですのでどうぞよろしくお願いします感想もぜひ それでは今回ありがとうございました

B

ありがとうございました。

✨ This transcript was generated by Metacast using AI and may contain inaccuracies. Learn more about transcripts.
For the best experience, listen in Metacast app for iOS or Android