0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Linuxの生みの親もClaude Codeを使う時代。AIで毎日直すアプリは、点検も「ローリング」にしよう

0
Last updated at Posted at 2026-10-19

AIで守るローリング点検.png

今朝(2026年10月19日)、「Linuxで今後ローリングリリースが主流になるかもしれない」という記事がZDNET Japanに載りました。ローリングリリースは、修正や変更ができるたびに少しずつ更新していく出し方です。きっかけの一つは、Linuxの生みの親であるLinus Torvalds氏が、カーネルの改善にClaude Codeを使ったこと。あわせて、AIがバグや脆弱性を見つける速さが上がり、人が修正を出すペースが追いつかなくなりつつある、という話も伝えられています。

この話は、AIでアプリを作っている個人開発者にもつながります。Claude CodeやCursorを使うと、コードを直す速さは一気に上がりました。それなのに、安全を確かめるのは「公開前に1回」のまま、という人は多いのではないでしょうか。

この記事では、Linuxのニュースをかみくだいて紹介したうえで、作る速さに合わせて確かめる習慣をどう変えればいいかを、明日から試せる形でまとめます。

Who am I?

BPR Prot. という、AIで作ったWebアプリの公開前の確認を手伝うサービスを作っています。Xでは、セキュリティや公開前に見落としやすいポイントを日々発信しています。よければご覧ください!

Linuxで何が起きているのか

Torvalds氏がClaude Codeを使ったのは、同じファイルを多くの処理が少しずつ読むときの競合を減らす改善です。10月11日に noref-filemap-read-with-llm というブランチで公開されており、コードとテスト、レビュー、説明文の初稿までを、自分の指示のもとでClaude Codeに作らせたと書いています。ただし、この変更はまだ本流にマージされていません。

もう一つの変化は、AIが見つけた穴を長く伏せておけなくなったことです。The Registerが伝えたTorvalds氏の発言によると、AIで見つかるバグは、ほかの人も同じようにAIで見つけられるので、そもそも秘密にはなりません。修正から3時間以内に解説ブログが出た例も挙げられていました。

ただ、現場の見方は一つではありません。同じ記事で、安定版カーネルのメンテナーは、修正件数に目立った増加は見ていないとも話しています。ローリングリリースが主流になるという部分も、ZDNETの記事の筆者による予測です。

「まとめて出す」と「少しずつ出す」の違い

Linuxの配布の仕方には、大きく2つの方式があります。

方式 代表例 更新の出し方 古い版の扱い
標準リリース Ubuntu、Debianなど 半年ごと、または2年ごとにまとめて出す 支えている古い版にも、修正を戻す
ローリングリリース Archなど 更新が来るたびに継続して出す 支えるのは最新の1つだけ

標準リリースとローリングリリース比較.png

標準リリースで大変なのは、古い版の面倒も見続けることです。たとえば最新版で見つかった穴を直したとしても、何年か前の版を使い続けている人がいれば、そちらにも同じ直しを入れなければなりません。ところが古い版は今のコードと作りが違うことがあるので、直しをそのまま持っていけず、古い版に合わせて作り直すことになります。これを「バックポート」と呼びます。Ubuntuは今、5つの版を同時に支えているので、穴が1つ見つかるたびに、この作り直しが何本も発生します。

ローリングリリースなら、支えるのは最新の1つだけです。古い版に合わせる作業がないので、見つかった穴を直してすぐ届けやすい、というのが記事の筆者の見方です。

個人開発に置き換えると、ずれが見えてくる

もちろん、Linuxの配布の仕方と、個人開発のアプリの安全確認は、別の話です。ただ、2つには共通する考え方があります。変更をためこまず、小さな単位で続けて扱うほうが、あとで困りにくいということです。

AIで作るアプリは、作る側はすでにこの考え方で動いています。思いついた日にAIにコードを直してもらい、そのまま公開する。決まった時期まで変更をためることは、まずありません。それなのに確かめる側だけが「最初の公開前に1回」で止まっていると、作る速さと確かめる速さがずれていきます。

それに、こまめな更新は、それだけで安全になるわけではありません。変更が増えれば、新しい不具合や穴が入りこむ機会も増えます。だから更新と確認は、セットで回す必要があります。

AIが「直しました」と言っても、それで終わりではない

わたしたちは以前、AIにエラーを直してもらうと何が起きるかを実験しました。そのうちの1つが、AIで文章を要約するアプリです。画面の側からOpenAIを呼ぼうとしてキーが読めず、要約ボタンを押すと止まってしまう、という状態のアプリを用意し、Claude CodeとCodexにそれぞれ3回ずつ直してもらいました。

6回とも、AIはキーをサーバーの側で使う形に作り変えて直しました。キーを画面に出してしまうような危ない直し方は、1回もありませんでした。ところが、そのために新しく作った窓口(API)には、6回ともログインの確認も回数の制限もありませんでした。URLを知っていれば誰でも呼べて、料金はキーの持ち主に請求される形です。そして、AIの返答は6回ともこの点に触れていませんでした。

公平のために書いておくと、元のアプリにはログイン機能がなく、依頼にも含めていなかったので、これはAIの間違いとは言えません。回数も6回だけの小さな実験です。それでも、AIは頼まれた問題を解決してくれても、その変更で生まれた別のリスクまで説明してくれるとは限らない、ということは見えてきました。詳しい条件と結果はこちらの実験記録にまとめています。

明日からできる3つのこと

1. 使っている部品の更新をためこまない

アプリの中では、ほかの人が作ったプログラムの部品(依存パッケージ)をたくさん使っています。Torvalds氏は、Linuxのメンテナーは対応できる一方で、小さなOSSは押し寄せる報告に圧倒されるかもしれないとも話していました。アプリが使っている部品の多くも、そうしたOSSです。

部品の側で修正が増えていくなら、更新を長くためるほど、あとでまとめて上げるときに大変になります。Linuxのバックポートと同じ構図です。GitHubのDependabotのように更新を知らせてくれる仕組みを使うと、届いた更新を小さいうちに受け取れます。

ただし、AIに「全部最新にして」とまとめて頼むのはおすすめしません。更新でアプリが動かなくなることもあるからです。まずはどの部品に更新が来ているかを見て、セキュリティの修正を含むものから1つずつ上げ、上げるたびにいつもの操作が動くかを見るくらいがちょうどいいです。

2. AIに直させたら、何が変わったかを説明させる

AIが「直しました」と返してきたら、終える前にもう一度だけ聞いてみてください。次の頼み方なら、コードが読めなくても、変更で何が変わったかを説明してもらえます。

今回の修正について、次の3つを確認して、専門用語を使わずに説明してください。
1. ログインしていない人が使える機能は増えていないか
2. 他人のデータを見たり変えたりできるようになっていないか
3. 有料APIなど、使うたびに料金がかかる機能の呼び出し方は変わっていないか

気になる答えが返ってきたら、その場で直しを頼めます。ただ、AIの説明だけで安全だと言い切れるわけではありません。あくまで、見落としに気づくきっかけとして使うのがおすすめです。

3. 公開するたびに、自分の手で3つだけ触ってみる

最後は、AIに聞くのではなく、自分で実際に操作してみる確認です。公開の前に、次の3つだけ試します。

  • ログアウトした状態で、ログインした人向けの画面や機能を開いてみる
  • 別のアカウントでログインして、最初のアカウントのデータが見えないか見てみる
  • ログアウトした状態で、料金がかかる機能(AIの呼び出しなど)を使えないか試してみる

これだけで全部の穴が見つかるわけではありませんが、実験で見えたような「誰でも使えてしまう」状態には気づきやすくなります。毎回すべてを調べきろうとすると続かないので、まずはこの3つを公開のたびの習慣にするところからで十分です。

作る速さが変わったなら、確かめる習慣も合わせて変えていけばいい。少しずつ更新するなら、確認も少しずつ繰り返す。それがAIと一緒に作り続けるときの、無理のない守り方だと思います。

開発の流れに点検を組み込みたい場合は、BPR Prot. のMCP連携もあります(Proプラン)。Claude CodeやCursorから診断を呼び出し、変更後の確認を続ける形です。
https://bpr-prot.com/?utm_source=qiita&utm_medium=article&utm_campaign=qiita_linux_rolling&utm_content=mid

わたしたちについて

ここまでの確認は、特別なツールがなくても今日から始められます。ただ、変更のたびに点検を思い出して、毎回自分で回すのは、正直なかなか大変ですよね。

わたしたちが作っているBPR Prot.には、Claude CodeやCursorから診断を呼び出せるMCP連携という機能があります(Proプラン)。つなぐと、AIがコードを書いたり変えたりしたときや公開の前に、自分から診断を呼ぶよう促す指示がAIに渡されます。AIが毎回必ず呼ぶとは限りませんが、点検をふだんの開発の流れに組みこんで、「確かめる側」もローリングにする手段の一つになります。

BPR Prot.は、AIで作ったアプリ・Webサービスのローンチ前の最終確認から、公開後の見守りまでを、ひとつのツールで伴走するサービスです。

  • URLを入れるとWebサイトのセキュリティをA〜Fで採点
  • コードの脆弱性診断
  • ファイルのマルウェア検査
  • 開発中に直接診断を呼び出すMCP連携(Proプラン)

Web診断・コード診断・マルウェア検査は無料プランでも使えます。公開前や変更後の点検に、よければご活用ください!

Xで話しかけてもらえるとめちゃ嬉しいです!記事の感想もお待ちしています!

最後まで見てくださりありがとうございました。
それでは良い開発ライフを!ノシ

出典

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?