おはようございます！ zenncast、MCのマイクです。11月5日、木曜日、朝7時になりました。今日もZennでトレンドになっている記事を、皆さんと一緒にチェックしていきます。
今朝ご紹介するのは5本です。AIを活用したセキュリティ検査から、画像エンコーダーの開発、AIと進める要件確認、そしてGitHubの秘密情報を守る設定まで。開発と運用のヒントを、じっくりお届けします！
....
まず1本目は、AIによるセキュリティレビューと、実際にアプリを動かす攻撃テストを自動化する取り組みです。
こちらでは、PRごとにAIが変更内容と周辺のコードを読み、セキュリティ上の問題をコメントします。レビューでどんな点を確認するか、その観点もコードと一緒に管理して、実行ログはGitHub上に残す仕組みです。
さらに、OpenCodeとDocker、GitHub Actionsを組み合わせて、毎週、自動で攻撃テストを実施しています。たとえば、権限のないユーザーが非公開の情報を取得できてしまわないか。こうした、コードを読むだけでは見つけにくい問題を、実際にアプリを動かしながら調べるんですね。
もちろん、試験をするのは本番ではなく専用の環境です。DockerでAIの通信先を制限し、外部サービスは、その動作を模した代替ツールに置き換えています。実行するコマンドも別のAIが審査するなど、検査する側の動きにも安全策を設けています。
APIキーはAIに直接渡しませんし、結果を投稿する作業も、あらかじめ決めた処理に任せています。AIに仕事は頼むけれど、必要以上の権限は渡さない、という設計です。
見つかった問題は非公開のIssueに集約し、誤検出や修正済みの指摘を除いたうえで、修正と次回の検査の改善につなげます。
AIにチェックしてもらって終わりではなく、安全に動かす仕組みと、結果を改善につなげる流れまで整えている。ここが参考になる取り組みですね。
....
続いて2本目は、AI時代のセキュリティ運用で、何を減らし、何に集中するか、というお話です。
AIによって、開発だけでなく攻撃のスピードも上がっています。そんな中で従来どおりの運用を続けていると、セキュリティ担当者の負担が増えてしまう恐れがある、と筆者は指摘しています。
そこで大切なのが、攻撃される入口と、管理にかかる手間を減らすこと。そのうえで、本当に重要な判断や対応に集中すべきだ、という考え方です。
具体例として挙げられているのは、SSH用のポートを開けずに接続する方法や、OSの更新をAWSに任せられる構成への移行です。守る場所や、自分たちで管理する作業そのものを減らしていこう、というわけですね。
そして、AIによって構成変更の手間が減った今こそ、静的ファイルの配信方法や、不要な警告が大量に出る運用も見直すタイミングだとしています。日々の管理や警告への対応に追われすぎないようにして、高度な攻撃に備える余力をつくるんですね。
セキュリティ対策というと、つい何かを追加する方向で考えがちですが、入口や手間を減らすことも大切な対策。運用を見直すときに、持っておきたい視点です。
....
3本目は、Noetraによる画像エンコーダーの開発についてです。
画像エンコーダーは、画像をAIが扱える数値に変換する仕組みです。Noetraは、その学習データや学習の過程を把握できるように、この画像エンコーダーを一から開発しました。
用意したのは、公開データから整えた24.4億組もの画像とテキストです。そこにAIが生成した画像の説明も加え、シンプルな対照学習で訓練しています。対照学習は、画像と、それに対応するテキストの関係を学ばせる方法ですね。
評価では、英語でSigLIP2と同等、日本語と中国語では、それを上回る性能を達成しました。
さらに、画像も扱えるLLMに組み込む実験も行っています。こちらでも、特に日本語の資料や文書を理解する場面で、優れた結果を示したそうです。
公開データを使っていても、データの品質や学習方法を工夫することで、高性能なモデルをつくれる。そのことを示す成果になっています。
データの規模だけでなく、何を使い、どう整えて、どう学ばせるか。日本語の資料を扱う場面での強さも含めて、注目したい開発ですね。
....
続いて4本目は、AIに実装を頼む前の、要件確認の進め方です。
重視しているのは、AIにいきなりコードを書かせるのではなく、実装前に曖昧な要件をなくすこと。まずは、実現したい目的と、その背景を聞きます。そこで認識を合わせてから、詳しい仕様を確認していく流れです。
聞き漏らしを防ぐため、確認項目も固定します。特に、空欄がある場合や大量のデータを扱う場合にどうするか。既存のカスタマイズと衝突しないか。表示速度やスマホ対応はどうするか。このあたりは、確認せずに進めると、あとから作り直しにつながりやすいポイントです。
質問の言葉選びも大切です。「イベントハンドラ」のような開発用語ではなく、「保存ボタンを押したとき」といった、業務の言葉で確認します。一方で、項目の内部コードや実際のデータは、kintone MCPサーバーを使ってAI自身が確認するようにしています。
質問は1回に1つ。選択肢は2個から4個に絞ります。推測できる内容なら案を添えて確認し、一度確定した内容は聞き直さない。答える側の負担も抑えながら、必要なことを詰めていくんですね。
決まった要件は文書に残し、実装後は公式ガイドラインと照合します。追加した機能も一覧に記録して、次の開発でAIが既存の変更を把握できるようにします。
AIに上手に書いてもらうには、まず、何をつくるかを一緒にはっきりさせる。質問の仕方から記録の残し方まで、実践しやすい工夫が詰まっていますね。
....
最後の5本目は、GitHubのsecretを守る設定について。保護設定を移行するときに、気をつけたいお話です。
まず前提として、GitHubでwrite権限を持つ人は、workflowを作って、リポジトリのsecret、つまりAPIキーなどの秘密情報を読み出せます。そのため、重要なsecretはenvironmentに置き、利用できるブランチを制限することが基本の対策になります。
ここで注意したいのが、「Protected branches only」という設定です。2026年10月に行われた検証では、この設定がブランチの保護として認識したのは、classic branch protectionだけでした。
rulesetだけでは制限がかからず、全ブランチにsecretが渡る状態になる、ということです。つまり、rulesetへ移行する際に、従来の保護設定をすべて削除すると、意図せずsecretの利用制限が外れてしまうんですね。
記事で勧めている対策は、「Selected branches and tags」を使い、mainなどのブランチ名を完全一致で指定することです。
パターンで指定する場合には注意が必要です。write権限を持つ人が、その条件に合う名前のブランチを作れてしまうからです。
mainにclassic branch protectionを残す方法でも回避できますが、記事ではあくまで暫定策としています。推奨しているのは、ブランチ名の完全一致による指定です。
保護設定を新しくしたつもりでも、別の設定との組み合わせで、守り方が変わってしまう。移行のときは、ブランチ自体の保護だけでなく、secretをどこから使えるかまで確認しておきたいですね。
....
さて、今朝のzenncastは、5本の記事をお届けしました。
AIによるレビューと毎週の攻撃テスト、攻撃の入口と管理の手間を減らすセキュリティ運用、Noetraの画像エンコーダー開発。そして、AIとの実装前の要件確認、GitHubのsecretを守るブランチ設定のお話でした。
詳しい内容はショーノートにまとめていますので、気になった記事はぜひチェックしてみてくださいね。
番組の感想もお待ちしています。「この話が参考になった」「自分の現場ではこうしています」など、皆さんの声を聞かせてもらえるとうれしいです。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入ったら、登録や高評価で応援していただけるとうれしいです！
それでは、次回も皆さんにお会いできるのを楽しみにしています。今日もすてきな1日を。zenncast、マイクでした！