「あの人も読んでる」略して「も読」。さまざまな寄稿者が最近気になった情報や話題をシェアする企画です。他のテックな人たちがどんな情報を追っているのか、ちょっと覗いてみませんか？
こんにちは。馬場（netmarkjp：Bluesky/X）です。
わたしは「#ばばさん通信ダイジェスト」として、BlueskyやThreadsに毎日少しずつ、賛否を問わず話題になった／なりそうなものを共有しています（Bluesky検索）。
これらをベースに、特にクラウド／インフラ／SRE／オブザーバビリティ／運用等のキーワードに関する話題を中心にお届けします。
変化が続くTLS証明書運用
AWSのブログで、AWS Certificate Manager（ACM）での証明書発行におけるドメイン所有権確認について、メール検証の廃止予定と、DNS検証への移行スケジュールや手順の解説が公開されました。
『This change aligns with the Certification Authority/Browser (CA/B) Forum’s industry-wide deprecation of email-based domain validation...』とのことで、このメール検証の廃止はCA/Browser Forumの方針に沿ったものとのことです。
CA/Browser Forumと言えば、2月の本連載で紹介した「TLSサーバー証明書の最大有効期限を段階的に短縮する」件もCA/Browser Forum方針です。
全ての証明書の最大有効期限が2月の本連載のタイトルのように6日間になるわけではありませんが、（プライベートCA等を除き）一般の証明書は2029年3月15日以降は47日間になります。
メール検証での更新は、DNSと比較して確実性と自動化に難がありますから、DNS検証に移行するのは良い選択肢だと思います。
実生活に沿った監視設定の裏を想像する
AWSから、Amazon CloudWatch Alarmsのウォールクロック評価ウィンドウが発表されました。
ウォールクロックは壁掛け時計のことですが、コンピューター用語では実時間を指すことがあります。敢えて「実」時間と言っているのは、CPU時間との対比によるものです。
CloudWatch Alarmsのwall clock evaluation windowでは、監視の評価ウィンドウを、「時刻ちょうど」などのカレンダーベース・暦日ベースに合わせられるようになります。つまり「0:00から5分間ごと」等がきっちりできるようになります。
毎日の0:00、毎週月曜の9:00等、カレンダーベースで傾向が大きく変わり、それに従って評価方式や閾値を指定したいニーズに対応できるようになりますね。
クラウドプラットフォームから見ると、「カレンダー日時ピッタリに何かする」を利用者に開放するのはハードルが高そうです。その処理の時系列分散が難しいため、クラウドプラットフォーム側のキャパシティコントロールが非常に難しいのではと予想します。今回のこの機能はカレンダー日時ピッタリに何かを起動して負荷がかかるわけではなく、評価タイミングを示すものなので、だいぶマシなのかなー、などと妄想しています。
AI時代の「持続性」実現技法の選択肢
AWS DevOps & Developer Productivity Blog で、技術的負債をAIの力で自律的に分析し解消する「AWS Transform – continuous modernization」の一般提供開始についての記事が公開されました。
continuous modernizationというのがいいですよね。わたしは未検証ですが、期待通りに動けばSREのプラクティスで言うところのトイル削減に大きく寄与しそうです。
システムは作りっぱなしではいけない、とは言いつつも、古くから安定して動いているシステムのメンテナンスの優先順位はどうしても低くなりがちです。しかしそこが割れ窓になりがちです。そのような隙を小さくするためにAIの力を借りるのは良い方法かもしれません
AIで顕在化したソフトウェアの課題に対処した話として、CloudflareのブログでAIを活用してAstroのGitHub Issueをゼロに近づけている話が紹介されています。
Software Factoryは最近よく聞くキーワードです。プログラミングを「製造」と呼びソフトウェア開発を工場の生産ラインに見立てる考え方は昔からありましたが、多くの現場ではあまり肯定的に捉えられていなかったように感じます。しかし今は最先端の現場がSoftware Factory化しているというのはなんとも趣深いです。
AIの力で健全化が推進できるとなったとして、しかしそれにもコストはかかります。そこでリファクタリングです。
Thoughtworksのmartinfowler.comで、AIエージェントによるコード生成におけるリファクタリングの経済的効果が解説されています。
リファクタリングによりソースコードの秩序を維持することは、維持コスト（この文脈ではトークン費用）の面でメリットがあるそうです。
コツコツと変化を繰り返すと、時に回り道になるようでいて、しかしトータルでのリスクが低く、持続性が高いものです。しなければならなかったが「手が回らず」できていなかったことを整えるチャンスかもしれませんね（もちろんそれが過剰品質な可能性もあるので、できなかったことをやればいいという話ではないのが悩ましいところです）。
AI時代のユースケースに応じた「ちょうどいい」Webブラウザーの形
Calibreのブログで、Linux向けarm64版Google Chromeのリリースについて解説したエントリーが公開されました。
Apple SiliconなmacOS上のUTMで動作しているarm64のLinuxでGoogle Chromeを公式ウェブサイトからインストールすると、確かにGoogle Chromeが利用できます。
arm64のコンピューティングリソース、例えばAWSだとGravitonは、Intel系（x86）と比較して安価に利用可能なことが多いですよね。
ChromiumではなくGoogle Chromeがarm64で動作することで、クロールやテスト等「できることならば本物のブラウザーが動いて欲しい」ケースでの選択肢が増えます。
ブラウザーと言えば、新たなブラウザーの話題もありました。
それぞれAI時代の新たなユースケースに特化した「ちょうどいい」ブラウザーを求めての活動に思えます。
それに、AIでの力技一辺倒ではなく、適材適所で社会レベルでの「ちょうどいい」効率の程度を実現していくのは格好良いですね。
透明性でセキュリティを支える仕組みと、実態を踏まえた運用の選択肢
Cloudflareのブログで、Certificate Transparencyログ（CT Log）監視機能の一般提供開始についての記事が公開されました。
現代のWebサイトやWebサービスにはHTTPSが欠かせません。そしてHTTPSにはTLS証明書が欠かせません。Certificate Transparencyログは、証明書の発行を「発行したことを公開することで、透明性をもって安全性を実現する」ための情報や仕組みを指し、わたしたちが利用するブラウザーの中でも、このCertificate Transparencyログを利用した証明書の検証が行われているそうです。
セキュリティと言うと隠すことが思いつきがちですが、セキュリティは機密性・完全性・可用性・真正性・責任追跡性・否認防止・信頼性の7要素をバランスよく満たして実現するものですから、セキュリティレベルを高めるために公開するというのはじゅうぶんにあり得るわけです。
主にシステムを開発・提供するわたしたちとしては、TLS証明書を取得したドメイン名が公開されていることを念頭におき、ドメイン名やサブドメインから機密漏洩するような迂闊な命名をしない、広く一般からの接続を前提にしていない場合は適切に接続制限を行う、立ち上げたばかりであったり本番環境でないからといってこのあたりの実現レベルを下げない、といった取り組みが必要ですね。
AIエージェントと協働するための、知識・検証・仕事の型化
Google Cloudのブログで、OKF（Open Knowledge Format）のv0.2について記事が公開されました。
OKFについては本連載の先月号で『AI時代のデータフォーマットOKF』として紹介しましたが、端的にAIエージェントと人間の両方が読み書きしやすいドキュメントとナレッジのオープン仕様です。
OKFでは、ドキュメントフォーマット（YAMLフロントマターとMarkdown）、ディレクトリーレイアウト、予約ファイル名とその意味に関する規約を定めています。
v0.1→v0.2では、来歴（Provenance）、信頼性（Trust）、鮮度とライフサイクル（Freshness and lifecycle）に関わるフロントマターが追加で定義されました。
また証明（Attestation）について、Attested Computationというtypeが追加で定義されました。
これはエージェントが何らかの抽出処理や集計処理を行うにあたり、以下を実現できるようにする仕組みです。
- 1: まず事前にMarkdownファイルとして処理方法を定義しておきます。これは例えばパラメーター化されたSQLそのものです。またMarkdownファイルには、実行系（スキル（skills）等）と、証明系（実行された処理自体を機械的かつ決定論的に検証するプログラム等）の指定も記述します
- 2: 実際に抽出処理や集計処理を行う際には、エージェントにそのMarkdownファイルを参照させて処理を実行させ、結果を受け取る側（典型的には自身ないし別のAIエージェント）がMarkdownファイルに指定された通りの処理方法が遂行されたかを機械的に確認できる
「仕事」を定義し任せることを型化していい感じですね。
AI利用判定は扱いが難しいし、もしかしたら自己矛盾をはらんでいるかも
難しいのは「この文章はAIが生成した確率が99%という判定」は「この文章はAIが生成したものだとは言っていない」というところで、AIが生成したかをtrue/falseで判断することは結局できないということですね。わたしは、これは単体で学生のレポートの合否判定に利用するのは筋違いの技術だと認識しています。
仕組みとしては「不自然な偏り」を仕込むということですが、何年か経ってAI生成された文章が一定量を占めたら、AI生成された文章が自然な文章と判定されるようになる可能性もあります。それにAI生成された文章に慣れ親しんだ世代にとっては「AI生成された文章のほうが自然な文章」となるかもしれません。
一般の期待と技術的な期待とが大きくズレる、過渡期の技術という感じがします。
個人的には、いずれにせよちょっと読んで続きを読むか判断するし、長ければまずAI要約して読むので、誰が書いても実際はあまり変わらないかもしれません。
AIで業界激変の時代だけれども、原理原則が分かればあんまり怖くない
わたしがオンラインイベントでお話したときの資料です。
丁寧な柔らかい口調で刺激的なことを言っていたという評判も聞きましたが、アンケートからは幅広い層から好評で一安心でした。
現状を踏まえてわたしの認識している原理原則や価値観をお話しつつ、最終的に次の4つの問いかけをしています。
みなさんも、将来に思いを馳せるタイミングで、ぜひ考えてみてください。
- 1: あなたは自分が開発している対象について、購買者視点で受容可能な範囲で、品質/保証を下げて他の指標を上げる具体的な品質の程度を判断／決定できますか？
- 2: Software Factoryや「プログラミング」の再定義（品質管理軸への転換）が話題です。あなたはこの「再定義」が成立すると考えますか？
- 3: プログラミングに限らず、読む能力と書く能力はセットです。プログラミングについて、あなたは「（現在の意味での）書く能力」がなくなっても、最低限の機能的便益の実現は可能だと考えますか？
- 4: わたしたちは、機能的便益（有用性）、機能的便益（保証）、情緒的便益、自己表現的便益、どこをどう組み合わせて提供することで食っていきましょうか？
注目・期待の書籍
『基礎と実践が1冊で学べる！ DNSマスターブック | 技術評論社』
山口崇徳 著
DNSを基礎からしっかり理解し、実際の運用現場で迷わず実践できるようになることを目的として本書は執筆されました。本書では、読者のレベルと目的に合わせて段階的に学べる「3部構成」を採用しています。
第1部：入門編 〜ITに関わるすべての人へ〜
まずはドメイン名とDNSの概念、基本的な仕組みをわかりやすく解説。DNSを専門に扱うエンジニアでなくても、「インターネットの裏方」として知っておくべき必須知識がここに詰まっています。
第2部：上級編 〜プロトコルと運用の本質を知る〜
DNSのプロトコルへの理解をさらに深め、リソースレコードの登録・運用に必要な実践的知識を解説。どのような情報を登録し、それがどうやり取りされるのか、データの流れを正確に把握できるようになります。
第3部：実践編 〜サイバー攻撃から守り抜く〜
DNSに登録されるデータではなく、「DNSサーバーそのもの」に焦点を当てます。近年多発するサイバー攻撃の脅威を踏まえ、安全で堅牢なサーバーをどのように設計・構築・運用すべきかを徹底解説します。
本書では、BINDなど個別の実装の具体的な設定方法などについてはあえてほとんど触れていません。特定の実装に関する記述に偏り、その実装でしか役に立たない手順を覚えるよりも、DNSの本質的な仕組みを理解できるようになることに重点を置きました。表面的な設定マニュアルから卒業し、本質を理解した強いエンジニアになりたい。本書は、そんなあなたのための1冊です。
『OpenTelemetryではじめるテレメトリーサンプリング | 技術評論社』
山口能迪 著
オブザーバビリティの重要性が高まる一方で、導入後に直面するテレメトリーデータの爆発的増加というジレンマを抱えたチーム、組織は多いのではないでしょうか。分散トレーシング、メトリクス、ログなどの計装が充実するほどデータ量は膨張し、ストレージコストの増大、分析基盤の複雑化、重要なシグナルの埋没といった問題が顕在化します。本書は、著者が約10年にわたり現場で見てきた問題意識を背景に、サンプリングを中心とした実践的なテレメトリーデータ管理の知見をまとめた1冊です。確率的サンプリングからテイルサンプリング、動的サンプリングまで、規模に応じた戦略を整理し、さらにトレース・ログ・メトリクス・プロファイルを含む全シグナル横断のアプローチも紹介します。OpenTelemetryを用いた実装、ガバナンスやFinOpsの観点も含め、テレメトリーサンプリングを包括的に理解できる内容となっています。
おわりに
直近の話題から、わたしが気になったものを中心にお送りしました。
Blameless&Keep Constructiveで、Humility Respect Trust溢れるご意見・ご感想、誤りの指摘などいただけると幸いです。
さて、最近はこのコーナーで毎回トラコン（ICTSC: ICTトラブルシューティングコンテスト）の情報を紹介しています。
ICTSCはネットワーク・サーバー・ミドルウェア等の情報通信インフラを主な対象領域としたトラブルシューティングのコンテストです。参加はチーム戦で、本戦ではチームごとに論理的な演習環境と物理機器がアサインされ、物理機器を含めたトラブルシューティングも出題されます。
このICTSCは参加者が学生、運営も学生という珍しいイベントです。運営する学生たちを社会人の実行委員が支える形で10年以上運営してきています。最近は一次予選・二次予選・本戦があり、本戦では予選を勝ち上がった学生たちと運営でおよそ100名の「情報通信インフラに興味があり、行動力と相応の技術力を持つ」学生が集います。
ICTトラブルシューティングコンテスト2026では参加者募集を開始しました。予選応募締切は2026年9月5日（土）24時（日本標準時）とあまり期間はありませんが、参加資格のあるみなさんはぜひ奮ってご参加ください。もし近くに参加資格を満たす方が居たらぜひ教えてあげてください。
参加資格
全ての参加者は応募の時点で、全国の専門学校、高等専修学校、高校、高専、大学、大学院(博士後期課程修学者を除く）、短期大学に所属する学生であること
コンテスト開催期間中、チームメンバ全員が自力でコンテスト会場に来場できること
チーム単位での参加とし、チームは単一団体(同じ専門学校や高校、大学など)に在籍する3名以上、5名以下の人員で構成されること
ICTSCは完全ボランティアの任意団体でして、今年度からわたしが会長を務めることになったので、一生懸命宣伝しています。若者や入門者を育て裾野を広げることは、業界の持続に不可欠だと思って続けております。
またスポンサーは引き続き募集しています。賛同いただける方・ご協力いただける方はぜひお声掛けくださいませ。
ではでは。
