00:00
LinterとFormatterは、アプリ開発の序盤で入れておくのがベストです。 今後は、秘密情報が入った危険なコミットは、ベタリークスが事前にエラーにしてくれます。
で、数百万円の高額なAPI請求が来た事例がいくつもあります。 こんにちは、超実践AI論のたいちです。今回は、アプリ開発の最初にやると、運用コストを削減できる
Linter、Formatter、セキュリティ周りの設定というテーマでお話しします。 前回の動画で、Webコンテンツ分析アプリのブランチ運用の設定まで完了しました。
この動画を含むクロードコードを使ったアプリ開発の全工程は動画コースにしているので、全体を知りたい方は概要欄のリンクから見てみてください。
今回は、アプリ開発の最初にやっておくと、AIがバグを作るのを防いだり、トークン消費の節約にも役立つ
LinterとFormatter、そしてセキュリティ周りの対応をやっていきます。 Linterとはコードを機械的に解析して、書き方のミスやバグの原因になるところを見つけてくれるツールです。
プログラムのコードはこのように、一文字違うだけでもエラーになって動かなくなります。 AIでもこのようなコードの誤りは直せますが、コードの量が多くなればなるほど時間もかかりますし、
トークンも消費します。 一方でLinterなら、数千行数万行のコードでも数秒でチェックして、機械的にすべてのミスを検出できます。
だからこそ、LinterでチェックできるところはすべてLinterに任せ、 AIはアプリ全体やロジックの設計などに専念することで、より早く正確に低コストでアプリを作ることができます。
そして、フォーマッターはコードの書き方を決まったルールで自動整形してくれるツールです。
例えばこのように1行の末尾にセミコロンがなかったりあったり、間にどのくらい空行を空けるか、文字列をダブルクオートで囲うのか、シングルクオートで囲うのか、といった書き方のルールをフォーマッターが一律で決
めて自動整形してくれます。
フォーマッターが入っていれば、コマンド一発、もしくは保存した瞬間に、このように決まったルールで書き方を統一してくれます。
このコードの書き方を統一する作業も、AIではなくフォーマッターに任せることで、機械的に一瞬でやることができます。
そして、リンターとフォーマッターはチェック対象のファイルの種類によってベストなツールが異なります。
例えばこのようなTypeScriptのファイルをチェックするもの、Markdownファイルをチェックするもの、データベースを操作するSQLをチェックするもの、GitHub Actionsのコードをチェ
ックするもの、といった感じで、
アプリで扱っているファイルの種類によって、使うべきリンターやフォーマッターも異なります。
なので、アプリで使うプログラムやツールを一通り入れたら、こんな感じでプロジェクト内に適切なリンターとフォーマッターが設定されるかを聞くといいです。
僕が今回作るアプリでは、最初に基盤を作るときにある程度のリンターとフォーマッターは入れてくれていました。
ですが、GitHub Actionsのリンターやデータベースを操作するSQLのフォーマッターが入っていませんでした。
なので、新しい会話を開いて、足りていないリンターとフォーマッターを追加してもらいます。
モデルはOpus 5.5で、思考レベルは最大にします。
03:00
リンターとフォーマッターは、アプリ開発の序盤で入れておくのがベストです。
なぜなら、既存のコードが大量にある状態でリンターとフォーマッターを使うと、直す箇所が大量に出てきて、その修正だけでかなりのコストがかかるからです。
プログラムやツールをインストールした直後にリンターとフォーマッターを設定しておけば、
不導入には全くコストがかからず、それ以降にAIが書くコードは機械的にきれいになります。
今回は、僕がアプリを作るときによく使っているリンターとフォーマッターを追加で入れてもらいます。
JSCPDはコードの重複がないかを検査するリンターです。
例えば、足し算をする処理が5箇所に書かれていたら、それは無駄でしかありません。
ベストなのは、1箇所に足し算の処理を定義し、足し算を使う5箇所からは、その定義した処理を呼ぶことです。
JSCPDは、このような無駄な重複コードを機械的に見つけてくれます。
2つ目のNIPは、使われていないコードを検出するリンターです。
AIでアプリの修正を繰り返していると、今はもうどこからも呼ばれていない古いコードが残ることがよくあります。
NIPはこのどこからも呼ばれていないコードを検出して、不要なゴミをきれいにするために役立ちます。
ActionLintは、GitHub Actionsのコードが正しく書かれているかをチェックするリンターです。
JISMAは、GitHub Actionsのコードにセキュリティ上の問題がないかをチェックします。
例えば、適切な権限が設定されているか、機密情報を漏えいする作りになっていないか、
ウイルスを注入される恐れのある箇所はないか、といったことを調べてくれます。
そして、SQL Graphics Migrationsというのは、データベースを操作するSQL用のフォーマッター設定です。
最後のSHFMTは、シェルスクリプトというプログラム用のフォーマッターです。
説明は以上なので、早速インストールしてもらいます。
はい、導入が完了したようなので、クロードコードの報告とPRを確認して、デベロップにマージしました。
今度は、セキュリティ周りの設定をやっていきます。
いつものように、新しいワークツリーを作成して、新しい会話を開き、そのワークツリーのホルダーを開きます。
そして、思考レベルを最大にします。
今回の指示は、Renovateでライブラリやツールがアップデートされるようにして、です。
Renovateとは、アプリのライブラリやツールの更新を自動提案してくれる無料ツールです。
アプリはこのように大量のツールを組み合わせて作ります。
今はまだアプリの土台を作ったばかりなので、入っているツールも少ししかありません。
でも、これからアプリの開発を進め、基盤をさらに整えていくと、使っているツールはどんどん増えてきます。
そして、使っているツールのバージョンは、最初にツールをインストールした時の安定版や最新版をAIが入れてくれています。
これらのツールは、新しいバージョンが出たら、都度アップデートしなければなりません。
なぜなら、古いバージョンのままだと、機能やパフォーマンスも古いままで、
バグや最悪脆弱性というセキュリティ上の弱点が残ったままになるからです。
06:02
でも、使っている全ツールの新バージョンが出ているかを、人が定期的にチェックしてアップデートするのは現実的ではありません。
そこで使うのがRenovateです。
Renovateは、アプリのツールを週1回など設定した頻度で自動チェックし、
更新がある場合は、更新してPR作成までやってくれます。
Renovateが作ってくれるPRはこんな感じです。
アプリの中で使っているツールやライブラリを、どのバージョンからどのバージョンに上げたのかがPRの概要に書かれます。
そして差分を見てみると、実際にライブラリのバージョンが更新されていることがわかります。
さらにGitHub Actionsでテストを書いていれば、このようにツールのアップデートで不具合が起きてもすぐに検知できます。
実際、このPRではアップデートによって不具合が起きたので、PRのURLをAIに渡して不具合を直してもらいました。
そしてその不具合の修正コミットによってテストが全部パスしてマージしたという流れです。
Renovateでライブラリやツールの自動アップデートを設定していれば、人がやることはRenovateが自動作成したPRを確認してマージするだけです。
これでアプリのライブラリやツールを常に安全で最新の状態に保つことができます。
RenovateのPRが毎日作られるのは面倒なので、僕は週1回の頻度でPRを作成してもらうよう設定しています。
はい、Renovateの対応も終わりました。
これでライブラリの更新もバッチリといきたいところですが、まだ問題があります。
先ほどRenovateの更新を僕は週1回にしていると説明しました。
ですが、深刻度が高い脆弱性が見つかったときは即座に更新しなければ攻撃される恐れがあります。
そこで使うのがDependabotです。
Dependabotでは深刻度が高い脆弱性をGitHub上で即時にアラートを出すことができます。
なので、Dependabotのアラートが出たときは週1回のRenovateを待たず対象のライブラリを即時更新します。
新しいワークツリーを作成し、クロードコードでそのワークツリーを開いて、
Renovateの週1回の更新より前に対応すべき脆弱性はDependabotで対応したいと指示します。
そしてDependabotの対応も終わりました。
脆弱性修正のPRはDependabotが作って、Renovateは週1回の通常更新だけを担ってくれるようになりました。
ですがRenovateでも元々週1回の更新を待たずに脆弱性修正のPRは作ってくれるようでした。
しかしRenovateのチェックはpackage.jsonだけが対象で、その他のファイルに書かれた脆弱性は検知してくれません。
一方でDependabotを組み合わせることで、Renovateだけでは見切れない範囲も検知できるようになります。
Dependabotを使うにはGitHubでも対応が必要なので、そちらも設定します。
プロジェクトのリポジトリのSettingsを開いて、そこからAdvanced Securityへ移動します。
その中の設定で、このDependency Graph、Dependabot Alerts、Malware Alerts、それからDependabot Security Updatesをオンにして
いきます。
このDependency Graphの設定をオンにすると、ツールが遺存しているツールの脆弱性まで検知できるようになります。
そして、このDependabot Alertsの設定をオンにしないと、Dependabotが脆弱性を検知できません。
09:02
加えて、このMalware Alertsの設定をオンにすることで、アプリが使っているツールに入ったマルウェア、つまりウイルスなども検知することができます。
そして、このDependabot Security Updatesの設定をオンにすると、Dependabotが脆弱性修正のPRを自動で作成してくれるようになります。
これらのDependabotの設定をオンにしておくと、DependabotがGitHub上でも脆弱性を通知してくれるようになります。
具体的には、今このIssuesのところに1が出ていますが、脆弱性が見つかったときは、このSecurity & Qualityのところに1のような表示が出ます。
そして、マルウェアや脆弱性が見つかったときは、このSecurity & Qualityのメニューの中のDependabotの中で具体的なマルウェアや脆弱性の内容を確認できます。
現在はゼロ件なので何も表示されていません。
そして、最後に新しいワークツリーでBetter Leaksの設定をしてもらいます。
Gitで秘密カギやAPIキーといった機密情報をコミットしてはいけません。
なぜなら、GitHubやアプリから流出して、悪用される恐れがあるからです。
流出して数百万円の高額なAPI請求が来た事例がいくつもあります。
Better Leaksは機密情報のコミットを機械的に検知して止めてくれます。
なので、アプリ開発の最初のうちにBetter Leaksの設定もすべきです。
ちなみに、このGitの機密情報流出を防ぐツールはGitLeaksがよく使われていますが、
GitLeaksの原作者が開発する後継プロジェクトがBetter Leaksなので、
今から使うならBetter Leaksにすべきです。
Better Leaksの対応も終わりました。
Better Leaksを入れるまでは、秘密情報が入っていてもコミットもプッシュも止まりませんでした。
ですが、今後は秘密情報が入った危険なコミットはBetter Leaksが事前にエラーにしてくれます。
これで、アプリ開発の最初に対応すべきリンター、フォーマッターおよびセキュリティ周りの設定は以上です。
ここで一つお知らせです。
業務のAI活用の個別サポートや研修、システム開発などのお仕事は概要欄の公式LINEからお問い合わせください。
相談は無料です。
動画の内容やその他のご質問にも公式LINEで回答しています。
今回の内容をおさらいすると、プログラミング言語やツール、ファイル形式ごとに
ベストなリンターとフォーマッターをAIに選んでもらって最初に導入しました。
リンターで機械的に検知できるミスをなくし、フォーマッターでファイルの書き方を自動で統一できます。
次に、Renovateでアプリのツールやライブラリを自動更新する設定をしました。
そして、Dependabotで即時対応が必要な脆弱性はすぐに更新PRを作成するようにしました。
最後に、Better Leaksで機密情報がGitに入らないようにしています。
ぜひあなたのアプリにも、今回紹介したリンターやフォーマッター、Renovate、Dependabot、Better Leaksを導入して、
効率的で安全なアプリ開発環境を整えてみてください。
次回は、AIによるレビューをどのように行っていくのかを解説します。
概要欄にも今回の内容を解説した記事を貼っておきます。
それでは今日はこの辺で。