Apple が AI エージェントのリスクを理由に macOS のフルディスクアクセスの制御強化を表明して Techmeme の首位に入り、はてなブックマークでは上位 10 件の半数をヤマト運輸や第一生命への不正アクセスなど個人情報の事案が占める

ドキュメントの例示用に予約されたドメイン example.com のページ内容が最近変わったことについて、著者が IANA に理由を問い合わせ、受け取った返信を公開した記事。9 月 28 日時点のページは、許可なくドキュメントの例として使えるドメインで、運用での使用は避けるようにという短い説明だった。

コメントでは、Wayback Machine に残る数日前の内容を引用して新旧を比べる投稿が最初に付いた。その後は、新しい英文がコンマで独立節をつなぐコンマスプライスになっている点をめぐって、セミコロンにすべきだという指摘と、問題なく読めるという反論に分かれた。

セミコロンにすべきだと主張した投稿はその文自体がすべてコンマスプライスで書かれた冗談で、気づかずに訂正した返信に別の投稿者が種明かしをするやり取りもあった。他人の文章を直すときほど自分も誤るという「Muphry の法則」を紹介する投稿も出た。

Git 3.0 で新規リポジトリのデフォルトのハッシュ関数を SHA-1 から SHA-256 に切り替える計画について、移行の負担に見合わない高くつく誤りだと論じる GitButler のブログ記事。

コメントでは、Git のドキュメントには SHA-1 と SHA-256 の名前を双方向に対応づける仕組みがあり、ローカルを SHA-256 にしても SHA-1 のリモートと push や pull ができるため記事の論点の多くは解決するという反論が最初に付いた。これに対し、その仕組みは実際には実装されておらず、SHA-1 対応が消えれば互換性もなくなるという指摘や、記事の主眼はホスティング側がどちらのハッシュを公開するかにあるという指摘が続いた。

筆者の「信頼は配布経路にある」という主張には、GitHub がフォークのネットワーク全体でオブジェクトを共有しているため認証を破らずに偽造オブジェクトを紛れ込ませられるという指摘や、ミラーから取得してハッシュで検証する使い方を見落としているという指摘が出た。

Rust チームによる安定版 Rust 1.99.0 のリリース告知。コメントによれば、このリリースで C の可変長引数を取る関数を Rust 側で扱えるようになった。

コメントの多くは次のリリースに向き、1.100 ではカスタムアロケータと never 型が入るため大型リリースになるという期待が出た。公開直後の依存の版を避ける dependency cooldowns も加わると補足する投稿もあった。never 型については、ほぼ 10 年前から never-say-never クレートで安定版でも使えていたという指摘と、それにかけた言葉遊びが続いた。

以前 LD_PRELOAD で C の関数（mremap）を差し替えられなかったという投稿者は、可変長引数の対応を歓迎した。これを「C variadics」と呼ぶのは誤りで varargs と呼ぶべきだという主張と、可変個の引数を取る関数一般を variadic と呼ぶのが計算機科学の慣用だという反論も交わされた。

AI エージェントが加えたコード変更を人が理解するときの認知負荷を減らす方法を論じたブログ記事。Lobsters では vibecoding タグで投稿された。コメントによれば、コード中の概念に適切な名前を付け、人とエージェントで共有する語彙を整えることが中心になっている。

コメントでは、GLOSSARY.md をエージェントに参照・追記させているが名前の付け直しまでは思いつかなかったという声や、各要素の責務が説明されることでコード品質も上がるという声、用語をメインのルールに組み込んだことで大きな依頼での最初のコンテキスト探索が 2 万〜4 万トークン減ったという報告が出た。

共有の語彙はドメイン駆動設計の要でもあり AI に限らないが、LLM は人間以上に紛らわしい名前を気軽に作るという指摘があった。気に入らない「leaf」という関数名を一度承認したら他のエージェントがその名前を広め、コメントや changelog の案にまで現れたという体験談も出た。

LLM の普及によって、Web 開発の講座や電子書籍で教えてきた人たちが意欲と活動の持続性を失いつつあると論じるブログ記事。コメントに引用された一節では、開発者がオンラインに集まって学び、教え、面白いプロジェクトを共有することもなくなったと書かれている。

コメントでは、記事への冷淡な反応に落胆したという声があった一方、講座や本は昔から読み手の期待する価値で売れてきたという見方や、フロントエンドは変化が速く、最新のフレームワークを追い続けた人は市場価値を保ってきたので嘆く理由がわからないという意見も出た。

CPU の高速化が続いた時代に最適化が軽視されたのと同じく、次の LLM が埋めてくれると考えてイノベーションが止まるのではという懸念が示され、クロックの向上は 2005 年ごろに頭打ちになったという訂正が付いた。アクセシビリティは変化の少ない分野で基礎が重要だという指摘もあった。

AI エージェントを「部屋で一番怠惰なシニア開発者」のように振る舞わせ、書かなくて済むコードは書かせないためのスキル。例として、日付ピッカーを頼まれたエージェントが flatpickr を入れてラッパーコンポーネントやスタイルシートを書き始めるところを、最小限の記述で済ませる対比を示している。

計測は、FastAPI と React で構成された実在のリポジトリ full-stack-fastapi-template をヘッドレスの Claude Code で編集させ、残った git diff を採点する方式。12 の機能チケットを Haiku 4.5 で各 4 回実行し、スキルなしと比べてコード行数が 54%、トークンが 22%、コストが 20%、時間が 27% 減り、安全性は 100% を保ったとしている。

比較対象の簡潔文体スキル caveman はコード行数が 20% 減にとどまり、「YAGNI と 1 行で書け」というプロンプトは 33% 減だが安全性が 95% に下がった。過剰な実装が起きやすいタスクでは最大 94% 減になる一方、もともと最小限のコードではほぼ差がないという。

TypeScript の教育者として知られる Matt Pocock 氏が、自身の .agents ディレクトリで日常的に使っているエージェントスキルを公開したリポジトリ。GSD、BMAD、Spec-Kit のようにプロセス全体を握る手法は制御を奪い、プロセス内のバグを直しにくくするとして、小さく、手を加えやすく、組み合わせられるスキルを目指している。どのモデルでも動くとしている。

導入方法は 2 通りある。Claude Code のプラグインとして入れると、公式マーケットプレイスから読み取り専用のまとまりとして入り、作者の更新が自動で届く。skills.sh を使うと編集可能なスキルファイルがプロジェクトにコピーされ、手元で改変できる。両方入れると各スキルが重複するため、どちらか一方を選ぶよう案内している。

Codex など他のエージェントには npx skills@latest add で入れ、その際は setup-matt-pocock-skills を必ず選ぶよう求めている。Codex のネイティブプラグインはロードマップにあるという。

AI コーディングエージェント向けのデザインガイダンス。1 つのスキル、24 のコマンド、ブラウザでのライブな反復、AI が生成したフロントエンドデザインを検査する 61 の決定的な検出ルールで構成される。Anthropic の frontend-design スキルを出発点にしている。

どのモデルも同じ SaaS テンプレートで学習しているため、指示がないと、何でも Inter、紫から青のグラデーション、カードの入れ子、色付き背景の灰色文字、見出しの上の角丸アイコンといった同じ特徴が出るとしている。

/impeccable init がプロジェクトを調べて不足分だけを尋ね、対象読者、目的、制約、文体などの製品の前提を PRODUCT.md に記録し、視覚的なシステムは DESIGN.md に分けて残す。polish、audit、critique、distill、animate、bolder、quieter などのコマンドで AI と共通の語彙を持てる。決定的なルールは CLI とブラウザ拡張で LLM や API キーなしに実行できる。

AI エージェントにインターネットを読む能力を与える CLI。Twitter、Reddit、YouTube、GitHub、Bilibili、小紅書の読み取りと検索を 1 つの CLI で扱い、各サービスの API 利用料は不要としている。導入は、インストール手順の URL をエージェントに渡して頼む形を取る。

README は、YouTube の字幕が取れない、Twitter API が有料で検索できない、Reddit はサーバーの IP が 403 で弾かれる、小紅書はログインしないと開けない、Bilibili は汎用ダウンローダーが遮断される、Web ページを取得しても生の HTML で読めないといった状況を列挙している。

各プラットフォームに第一候補と予備の複数の接続方式を用意し、使えなくなれば次に切り替える。2026 年 6 月に yt-dlp が Bilibili に遮断された際は bili-cli に切り替え、利用者の操作は不要だったという。Cookie はローカルにのみ保存するとしている。

「ハーネスがモデルを包むなら、リグはハーネスを包む」として、Claude Code、Codex、Pi といったコーディングエージェントを、役割、共有コンテキスト、担当作業を持つ常駐チームとして束ねるオープンソースソフトウェア。エージェントのチームを YAML で定義し、1 つのコマンドで起動する。

利用者はリードのエージェントに望む結果を伝え、リードがチームをまたいで専門のエージェントを調整し、結果や人間の判断が必要な事項を持ち帰る。まずは 1 つのリポジトリと 1 つの有用な変更から始め、チームの作業とコンテキストを同じアドレスに保ち続ける使い方を想定している。作者の「AI 文明」実験を支える仕組みでもあるという。

TUI ではリグをグラフや席（seat）の表として表示し、各席のランタイム、モデル、コンテキスト、状態を確認できる。動作には Node.js 22 か 24 と tmux が必要で、macOS と Linux に対応する。

URL を貼るだけで、YouTube、X/Twitter、Instagram、Threads、TikTok など 1,800 以上のサイトから動画を保存できるターミナルアプリ。解像度か mp3 の音声のみを選んで保存する。npm install -g yoinks か npx yoinks で動き、Node 18 以上が必要。

中身は yt-dlp で、初回起動時にスタンドアロンの yt-dlp バイナリを ~/.yoinks/bin に取得するため Python は不要。高解像度ストリームの結合と mp3 抽出に使う ffmpeg は PATH から探し、なければ同梱の ffmpeg-static を使う。UI は React でターミナル UI を作る Ink 製。

全画面で起動し、矢印キーや j/k、数字キー、マウスで形式を選ぶ。保存先は ~/Downloads で、端末の前景色・背景色に合わせる auto テーマと light / dark を切り替えられる。

OpenShell は、自律型 AI エージェントの群れを安全かつプライベートに動かすための NVIDIA のランタイム。エージェントにファイルの読み書きやパッケージのインストール、API 呼び出し、認証情報の利用を許しつつ、データや秘密情報、ネットワークへの無制限なアクセスは与えない。各エージェントが触れてよい範囲をポリシーとして宣言し、OpenShell がそれを強制する。

仕組みは 2 つある。1 つはカーネルレベルの強制で、各エージェントを隔離したサンドボックスで動かし、ファイルアクセスとシステムコールをカーネルで制限し、ネットワーク接続はすべてサンドボックスを出る前にポリシーで検査する。エージェントには本物の認証情報を見せず、承認済みのエンドポイント宛てのリクエストにだけ OpenShell が付与する。

もう 1 つは形式検証で、ポリシー変更を適用する前に、認証情報を持った新しいホストへの到達や新しい API メソッドの呼び出しなど、変更で新たに許される危険なアクセスを洗い出して人間のレビューに回す。0.1.x では安定したリリース周期、新しい分離の仕組み、拡張ポイントと API の追加が告知されている。

HeyGen による、HTML、CSS、メディア、シーク可能なアニメーションを決定的に MP4 動画へ変換するオープンソースフレームワーク。CLI でローカルに使えるほか、AI コーディングエージェントからスキル経由で使ったり、ホスト型の制作ワークフローのレンダリング基盤にしたりできる。

Claude Code にはバージョン付きのプラグインとして入れ、/hyperframes:hyperframes で呼び出す。Copilot、VS Code、Cursor、Gemini CLI、OpenCode などにも対応し、npx skills add で入れる場合は Core Skills だけで足りるとしている。公開スキルは全 21 個で、skills.sh のレジストリは main より数時間遅れることがあるため、最新版が必要なときは npx hyperframes skills update を使うよう案内している。

スキルは、動画の計画、正しい HTML の記述、シーク可能なアニメーションの組み込み、メディアの追加、lint、プレビュー、レンダリングという制作の流れをエージェントに教える。

コーディングエージェント向けの開発手法一式で、組み合わせ可能なスキル群と、エージェントにそれを使わせる初期指示で構成される。Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot CLI、OpenCode、Pi など多数のエージェントへの導入手順を載せている。

エージェントは何かを作ろうとしているのを見ると、すぐにコードを書かずに本当にやりたいことを尋ね、会話から仕様を引き出して、読み切れる短さに分けて提示する。設計の承認後は、文脈を知らず判断力も乏しいジュニアエンジニアでも従えるほど明確な実装計画を作り、red/green の TDD、YAGNI、DRY を重視する。

利用者が「go」と伝えると subagent-driven-development のプロセスに入り、エージェントが各タスクを処理しながら成果物を検査・レビューして先へ進む。

AI コーディングエージェントのコンテキストウィンドウを最適化するツール。MCP ツールの呼び出しは生データをそのままコンテキストに流し込み、Playwright のスナップショット 1 回で 56 KB、GitHub の issue 20 件で 59 KB、アクセスログ 1 つで 45 KB を消費するため、30 分でコンテキストの 40% がなくなるとしている。

さらに、空きを作るために会話を圧縮すると、編集中のファイル、進行中のタスク、直前の依頼をエージェントが忘れてしまう。context-mode はツール出力をサンドボックスに隔離して約 98% 削減し、セッションの記憶を永続化し、MCP とフックを使って 17 のプラットフォームでルーティングを強制する。

ライセンスは Elastic License 2.0 で、Hacker News で 570 ポイント超を集めて 1 位になったことを README に掲げている。

AI がコードを書くようになり E2E とユニットテストのどちらを厚くすべきかという議論が増えたが、テストの種類ごとに検出できる不具合は違い、その役割は AI が来ても変わらないとして使い分けを整理した記事。

型・lint、ユニットテスト、PBT、integration テスト、E2E テスト、探索的テストについて、値の取り違え、境界値を含む計算の誤り、DB・永続化の誤り、画面をまたぐ結合の誤り、仕様の漏れなど不具合の種類ごとの検出力を表にまとめている。どの自動テストも書かれたことしか検証しないため、想定外の不具合は探索的テストで探すしかないとする。

AI に実装させテストが通るまで修正させる進め方では、1 回の反復の待ち時間と反復回数が生産性を左右する。速く失敗の原因まで示せる型検査、lint、ユニットテスト、PBT を反復の中のフィードバックに使い、遅い integration と E2E は結合や実環境の確認に集中させる方が活きるとしている。

2011 年から会社の指定で Git を使ってきた筆者が、2026 年に初めて自分の意思で VCS を選び、Jujutsu に移行した経緯と理由を書いた記事。Claude Code などの AI コーディングエージェントでコードを書く速度が上がり、Git の add と commit の手間や、理解が浅いまま commit したコードを後から直す rebase の失敗が日常的な負担になっていたという。

Jujutsu は設計思想もコマンド体系も Git と大きく異なり最初は使いこなせなかったが、インデックスが存在しない手軽さと、どの操作も undo で戻せる安心感から 1 か月ほどで扱えるようになり、現在はすべてのリポジトリと原稿執筆を Jujutsu で管理している。

戻れない理由の 1 つ目として、作業ディレクトリの状態がそのまま commit になるため、保存のタイミングを考えなくてよく、stash に相当する退避が不要で、作業中のコードを失う危険がほぼないことを挙げている。

トランザクションの中に処理を書く順番について、簡単な指針を紹介する記事。EC サイトの注文確定処理で、注文確定メールを送った後に在庫の引き当てで失敗してロールバックすると、確定していない注文の確定メールが利用者に残ってしまう例を挙げる。

Jim Gray の 1981 年の論文「The Transaction Concept: Virtues and Limitations」に基づき、処理を取り消しも再実行も要らない非保護（一時ファイルへの書き込みや読み取り）、ロールバックで戻せる保護（通常の DB 操作）、実行したら取り消せない実（メール送信や現金の払い出し）の 3 つに分類する。

解決策は実アクションを最後に実行することで、例ではステータス更新と在庫の引き当ての後にメールを送る順に書き換えている。実アクションが複数ある場合など、それでも困るときはトランザクショナルアウトボックスパターンを検討するよう勧めている。

サンフランシスコで開かれた OpenAI DevDay 2026 の発表を現地からまとめた記事で、加筆中としている。公式の Recap ページに載った発表は 25 項目で、キーノートでは Sam Altman CEO が dots、ChatGPT Space、GPT-6.1 Sol、Ultrafast、Decisions API などを紹介した。

主な発表として、GPT-6 Astra に近い性能を低コストで使える GPT-6.1 Sol、高速にトークンを生成する Ultrafast、Codex のクラウド環境と CLI、コードレビュー機能の強化、Computer Use に対応した Agents API、Sign in with ChatGPT、月額 500 ドルの Pro 500 を挙げる。

dots は GPT-6 Astra を使い、専用のクラウド上のコンピューターで与えた目標に向けて 24 時間動くエージェントで、4,000 を超えるアプリにプラグインで接続できる。対象は Pro と Business Premium で、dots 単体ではレートリミットを消費しない。

筆者が Rust で実装して公開している Unix 系 OS「octox」が、サンフランシスコ大学の 2026 年春学期の授業「CS 631: Systems Foundations」で教材として使われていたことを紹介する記事。授業の OS 部分でガイド、講義資料、実装課題に使われている。octox は xv6-riscv に触発され、ユーザーランドまで Rust で書いた学習用 OS。

授業サイトの「The Octox Guide」は、概念、コード、Rust での実装の解説の順に構成され、ブートからファイルシステム、同期機構まで扱う。システムコールの講義では fork、exec、dup2、pipe によるリダイレクトやパイプを、カーネルの講義では getpid() の ecall からトラップ処理、復帰までを追う。

仮想メモリの講義では Sv39 や walk()、mappages() を読み、アドレスを PAddr、KVAddr、UVAddr という別の型で表す設計も取り上げている。

Cloudflare が公開した次世代の統合 CLI cf（現在 v1.0.0-beta）への移行記録。従来の wrangler.json や wrangler.toml から、TypeScript ベースの設定ファイル cloudflare.config.ts への移行が推奨されており、公式の cf migrate コマンドもあるが、実行するだけではそのまま本番で動かないとしている。

移行の利点として、設定の型チェックと補完、cloudflare.config.ts から env の型を逆算する cf workers types、DNS や R2、D1 などを同じコマンド体系で扱える統合 CLI、Vite や React Router との連携、AI エージェントとの親和性の 5 点を挙げる。

React Router v8 と Vite による Workers のフルスタック構成と、キューやバッチの Worker を含むマルチ Worker 構成を例に、cf migrate から本番デプロイまでの手順と、遭遇したエラーと対処を整理している。

e-dash の QA チームが、テストケースの前に用意するテスト設計書のさらに前に、テスト要求仕様（TRS）を挟むようにした事例。従来のテンプレートは確認項目ごとにテスト観点と因子・水準を整理してテストパターンに落とす段階的な構造で、それ自体は有効だったが、対象が大きくなると全体を把握しにくくなっていた。原因は、何を 1 つの確認項目とするかの切り方が書き手の頭の中にしかなかったことだとしている。

TRS では、仕様レイヤーで「あるべき挙動」を確定させ、テスト設計レイヤーで「それをどう検証するか」を定義し、常に仕様からテスト設計の順に読み書きする。切り口はユーザーストーリー、ユースケース、正常・準正常・例外の振る舞い、受け入れ基準（AC）で決まる。

AC は BDD で使われる Gherkin で書き、<権限> や <操作> のような可変部だけを置いて具体的な値は書かない。値と組み合わせはテスト設計レイヤーの因子一覧が受け持ち、因子は可変データと 1 対 1 で対応させる。

2025 年度以降に業界に入ったエンジニアや上流工程を担う人に向けて、生成 AI の活用が当たり前になった時代の仕事への向き合い方を論じるエッセイ。生成 AI の活用自体は否定せず、自戒として書くとしている。同僚の仕様提案やレビュー、営業資料、顧客の要件定義までほぼ生成 AI の出力になった現状を挙げる。

創作を交えた事例として、AI 構文で埋まった議事録や仕様書を受け取ったエンジニアが Codex に基本設計書を書かせ、PL も設計書を読まずに社内レビュー AI の指摘をそのまま貼り、エンジニアがその指摘を再び Codex に渡して修正案と返信を作らせるという、人が AI の出力を中継するだけの「Meat Proxy」の構図を描いている。

結論として、この破綻は AI のせいではなく、当然求められる責任を自ら放棄した結果であり、責任を持てない生成 AI は副操縦士の域を出ず、人が介在する価値は意思と責任を持つことにあると主張している。

AI がコードを書くのが日常になり、時間の比重が「何を実装してもらうか」を決める側に移ったという実感から、AI 駆動開発で設計をどこに書くか、既存の設計成果物で実装をどこまで機械的に検証できるか、内部の振る舞いをテストで検証できる仕様にする方法の 3 つを考えた記事。結論として、仕様は AI と一緒に書き、仕様とコードの一致は決定的なプログラムで判定し、人のレビューは「この仕様でよいか」に重心を移すことを挙げる。

ユーザー一覧 API を例に、認可、並び順、ページネーションの方式、削除済みユーザーの扱い、性能、外部依存の失敗時の返し方など、事前に決めたい項目を表で示す。これらが曖昧でも AI は推論で空白を埋めて動くコードを書くため、空白があったこと自体に気づきにくいと指摘している。

設計を「要求を理解し構造に変換すること」と捉え、構造に付随する「なぜ」を残す方法として Design Rationale と、Michael Nygard が 2011 年に提案した ADR を紹介している。

X で見かけた「アウトプットしないことは知的な便秘だ」という言葉をきっかけに、筆者がアウトプットを続ける理由を書いた記事。アウトプットしない人を責める意図はなく、人によって適切な形と周期があるという前提を置いている。仕事で成果が出ずに悩んでいたとき、知人に「考えていることを排泄しよう」と言われたのが始まりだという。

アウトプットを、学習や経験で得た知識や考えを話す・書く・行動するといった形で外に出すことと定義し、筆者の場合は Qiita への投稿、JAWS-UG などでの LT 登壇、社内発表がそれに当たる。

続ける理由として、社内外に実績を示してエンジニアとしての価値を高めること、準備や反応を通じてインプットが増えるという循環、記事や登壇資料を作る過程で暗黙知が形式知に整理されることの 3 つを挙げる。Codex や Claude Code で並列にタスクをこなして頭が疲れる最近は、特に 3 つ目の必要を感じているという。

X で話題になった日本語推敲スキル yomiyasu を、natural-japanese、japanese-tech-writing と比べた記事。2026 年 10 月 1 日に Claude Code の Claude Sonnet（effort: low）を毎回新しいセッションで使い、--safe-mode でほかのプラグインや CLAUDE.md を止め、比較するスキルだけを加えて同じ原文と依頼文で実行した。

yomiyasu は文の骨格と曖昧な比喩を直し、検査用の yomiyasu_lint.py を同梱する。natural-japanese は設計から収束までの工程で段落構成まで扱い、japanese-tech-writing は技術文書向けの文章規範である。

結果は 3 つとも読みやすくなったが、yomiyasu は原文をかなり残し、natural-japanese は段落から組み直し、japanese-tech-writing は余分な表現を削った。1 つの原文を各 1 回通しただけで、優劣を決める検証ではないと断っている。

未経験から実務に入り、自分の関わるプロダクトでセキュリティの問題に直面した筆者が、基礎の復習として CSRF の攻撃と防御をまとめた記事。情報セキュリティを機密性・完全性・可用性の維持と定義し、リスク、脅威、脆弱性の違いを、送信回数に上限のないメール送信 API を例に説明している。

CSRF は、ログイン済みユーザーの権限を利用して、本人が意図しないリクエストを Web アプリケーションに送らせる攻撃。攻撃者は認証情報を盗むのではなく、悪意あるサイトから送られたリクエストにブラウザが認証 Cookie を自動で付けるため、サーバーからは本人の操作に見えるという点を強調している。

狙われるのはメール送信、パスワード変更、登録情報の変更、購入、削除、招待といった状態を変更する処理だとし、防御策は、ブラウザが一定の条件で Cookie を自動付与することが CSRF 成立の大きな理由だという点から検討を始めている。

AWS 認定の試験を公開直後に受ける「宇宙最速（未遂）受験」を続ける筆者による、AWS Certified AI Business Strategist の合格体験記。AWS 認定に 5 つ目のカテゴリ Business が加わった。試験ガイドには生成 AI を軸に KPI や ROI などビジネスの用語が登場し、推奨される AWS 知識として Amazon Bedrock、Amazon SageMaker AI、Amazon Quick が挙がる。

ベータ試験のため問題数は 85 問、合格点は 700 点で、試験時間は試験ガイドの 130 分に対し、申し込み時は 170 分と案内された。対策時間は空き時間を使って合計 5 時間程度。

対策はほぼ AWS Skill Builder の Official Practice Question Set で、初見の正答率は 70% だった。さらに Claude Code に試験ガイドを読み込ませて模擬試験を自作したが、正解の選択肢が誤答より長くなる傾向があったため調整したという。