はじめに

2026年10月14日、curl 8.23.0 が公開されました。リリースの数字の欄には「24 security fixes (total: 239)」。作者の Daniel Stenberg は「24 件もあるので」とリリースの記事で個別に並べるのをやめ、セキュリティのページを見てほしいと書いています。24 件のうち深刻度 High は 1 件、残る 23 件はすべて Low です。

その High の 1 件、CVE-2026-92392「HTTP/2 upload Use-After-Free」は、作者が「curl で久しぶりの最悪級の脆弱性の一つ」と呼ぶもので、条件がそろえばリモートでのコード実行（RCE）に届くことが示されました。見つけたのは Anthropic の Luna Tong 氏で、advisory のクレジットは「Luna with Claude, Anthropic」。同じ日に、AI を使った監査を続けてきた Aisle の監査報告も公開され、24 件のうち 18 件は Aisle Research の研究者が見つけたものです。

この記事のゴールは、自分の PC・CI・組み込み機器に入っている curl がこの 24 件に当たるかどうかを、curl -V の出力から 5 分で判定できるようになることです。そのために、use-after-free と HTTP/2 のフロー制御の基礎を押さえ、High の 1 件がなぜ RCE に届きうるのか、そしてなぜ「Critical ではなく High」なのかを確かめてから、残り 23 件の見取り図、Aisle の監査、手元での確認手順へ進みます。ディストロの対応状況は 2026年10月20日時点の一次情報の表記です。

📌 この記事の3行まとめ
  • curl 8.23.0 で脆弱性 24 件を修正。High は HTTP/2 でのアップロード中に起きる解放後使用（CVE-2026-92392・8.12.0〜8.22.0）の 1 件だけで、残りはすべて Low
  • High の 1 件は RCE まで実証されたが、成立には悪意のあるサーバーへのアップロードや環境の細部の一致など多くの条件が要り、作者は「最もありそうな結果はクラッシュ」としている
  • 確認は curl -V の版と Features 欄の HTTP2 から。curl 単体だけでなく、Git や各種アプリに同梱された libcurl も別々に更新が要る

🧠 1. use-after-free とは ── 返したはずのメモリを、まだ指しているポインタ

C 言語では、プログラムが自分でメモリを借りて（malloc）、使い終わったら返します（free）。返したメモリは、次に誰かが借りたときに別の用途で再利用されます。

ここで、返したメモリの番地を覚えたままのポインタが残っていると問題が起きます。これをダングリングポインタ（宙ぶらりんのポインタ）と呼び、そのポインタ経由でメモリを読み書きしてしまうのが use-after-free（解放後使用・UAF） です。作者のブログも、C のようなメモリ安全でない言語の「古典的な問題」と説明しています。

flowchart TD A["① 構造体を確保して使う
ポインタ p がそこを指す"] --> B["② 使い終わって free
メモリは返却済み"] B --> C["③ 同じ場所が別の用途で再利用
中身は別のデータに入れ替わる"] C --> D["④ 残っていた p で読み書き
別のデータを元の構造体だと思って使う"]

特に危ないのは、③で再利用されたメモリに入る中身を外部の誰か（攻撃者）が決められる場合です。プログラムは④で、その中身を元の構造体だと信じて使ってしまうからです。作者も「悪意のある者がその領域の中身に影響を与えられるとき、この種の誤りは特に悪い」と書いています。

curl のセキュリティのページでは、メモリ安全な言語なら起きなかったと見られる脆弱性に「C mistake」の印を付けています。今回の 24 件では、CVE-2026-92392 を含む 3 件がこの印付きです。

🔀 2. HTTP/2 の多重化とフロー制御とは ── 1 本の接続に何本もの転送を流す

HTTP/1.1 では、1 本の TCP 接続で同時に進められるリクエストは基本的に 1 つでした。HTTP/2 は、1 本の接続の中にストリームという論理的な通り道を何本も作り、複数の転送を同時に流します。これが多重化です。

多重化には、2 つの交通整理の仕組みが付いています。

  • フロー制御（WINDOW_UPDATE）: 受け手は「あと何バイトまで送ってよいか」というウィンドウを持ち、読み進めるたびに WINDOW_UPDATE で枠を広げます。ウィンドウが 0 のあいだ、送り手はそのストリームで送るのを待ちます
  • ストリームのリセット（RST_STREAM）: どちらの側からでも、特定のストリームだけを打ち切れます。接続そのものと他のストリームは続きます。打ち切りには理由のコード（たとえば REFUSED_STREAM＝処理せずに断った、HTTP_1_1_REQUIRED＝HTTP/1.1 でやり直してほしい）が付きます
sequenceDiagram participant C as クライアント participant S as サーバー C->>S: HEADERS（ストリーム 1・GET） C->>S: HEADERS（ストリーム 3・POST） C->>S: DATA（ストリーム 3・アップロード） Note over S: 受け手のウィンドウが残り 0 Note over C: ストリーム 3 の送信を待つ S->>C: WINDOW_UPDATE（枠を広げる） C->>S: DATA（ストリーム 3・続き） S->>C: DATA（ストリーム 1・応答） S->>C: RST_STREAM（ストリーム 3 だけ打ち切る） Note over C,S: 接続とストリーム 1 は続く

クライアントの側から見ると、1 本の接続の上で寿命の違う転送がいくつも同時に生きていることになります。どのデータがどの転送のものかを取り違えず、終わった転送の後始末を正しく済ませる。これが多重化のプロトコルを実装する側の難しさで、作者もブログの終わりで「寿命の違う転送が同時にいくつも走る多重化プロトコルでは、メモリ安全でない言語のダングリングポインタは致命的になりうる」と書いています。

🧩 3. libcurl の easy handle とマルチハンドルとは

libcurl を使うアプリは、転送 1 件ごとに easy handle という専用の入れ物を作ります。URL やオプション、転送の状態はここに入り、転送が終わればアプリが解放します。

複数の転送を同時に進めたいときは、easy handle をまとめて抱える multi handle を使います。作者の説明では、libcurl の転送には必ず multi handle と easy handle が少なくとも 1 つずつあり、multi handle はアプリから見えないところで内部的に使われることもあります。curl コマンド自身も libcurl の上で動いているので、ここで起きる問題はコマンドにもそのまま及びます。

入れ物 役割 解放するのは
easy handle 転送 1 件の設定と状態 転送が終わった後にアプリ
multi handle 複数の easy handle を束ねて同時に進める 最後にアプリ

HTTP/2 の多重化では、1 本の接続を複数の easy handle が共有します。接続の側が「どの easy handle がどのストリームか」を覚えておく必要があり、ここに次の節の問題が生まれました。

🔍 4. CVE-2026-92392 の中身 ── 条件の連鎖でつながった解放後使用

何が起きるか

advisory の説明は 1 文です。「アップロード中に、サーバーから受け取った HTTP/2 の RST_STREAM（理由が HTTP_1_1_REQUIRED または REFUSED_STREAM）を curl が誤って扱い、struct Curl_easy（easy handle の中身）の解放後使用につながる」。影響する版は 8.12.0〜8.22.0、curl コマンドと libcurl の両方です。

作者のブログは、これを次の流れで説明しています（簡略化した説明だと断ったうえで）。

flowchart TD A["アプリが HTTPS で HTTP/2 アップロードを始める
（相手は悪意のあるサーバー）"] --> B["サーバーがウィンドウを 0 にして送信を止め
応答の一部を返してからストリームをリセット"] B --> C["curl は転送を正しく終えるが
easy handle を指すポインタが 1 本残る"] C --> D["アプリは転送の終了（エラー）を知り
easy handle を解放 → multi handle の後始末へ"] D --> E["後始末の中で libcurl が
残ったポインタを見つけてしまう"] E --> F["解放済みの場所がサーバーから届いたデータで
埋まり、それを easy handle として使う"]

一つひとつは、HTTP/2 としてもアプリの使い方としても正当な動きです。フロー制御で止める、ストリームを打ち切る、終わった転送の easy handle を解放する、最後に multi handle を片付ける。この順番が重なったときにだけ、ポインタが 1 本取り残されます。

なぜ RCE に「届きうる」のか

第 1 節の図の③④にあたるのが、上の図の最後の段です。解放された easy handle の場所が、サーバーから受け取ったデータの置き場として再利用され、libcurl はそれを easy handle だと思って使い続けます。中身を決めているのはサーバーなので、作者は「この流れの先でリモートのコードが実行される」と説明し、advisory も「悪意のあるサーバーが特定の条件を満たせば RCE に変換できることが実証された」と書いています。

それでも「Critical ではなく High」の理由

作者と advisory は、実際に成立させるには多くの条件を同時に満たす必要があるとして、深刻度を Critical ではなく High にしました。挙げられている条件を、性質ごとにまとめると次のとおりです。

条件の種類 作者・advisory の記載（要約）
接続の相手 被害者が悪意のあるサーバーにアップロードしようとすること。サーバー証明書は有効なままである必要がある
環境の一致 curl の版・アーキテクチャ・構造体の配置を攻撃側が知っていること
メモリの使われ方 libc のアロケータ、nghttp2 と OpenSSL／TLS 1.3 の挙動、CA バンドルなどで決まる確保の順序と大きさが合うこと。ディストロや libc、アプリごとに違う
同時転送 2 本の並行転送とそのタイミングが合い続けること
書き込める量 実行できるコマンドは短いものに限られる（約 23 バイト）

作者は「実際の環境でこれらを満たすのは極めて難しい」とし、「攻撃を試みた場合に最もありそうな結果は、むしろ単なるクラッシュ」「成功の見込みは小さい」と見積もっています。curl のプロジェクトは自分たちの脆弱性に CVSS を付けない方針で、深刻度は Low／Medium／High／Critical の 4 段階で示しています。

報告から修正まで

報告は 9月15日。curl のセキュリティチームは数時間で確認し、次のリリースを前倒しすると決めました。ただし手順を飛ばして別の問題を生まないよう、リリースの間隔を 8 週間から 6 週間に2 週間縮める形をとり、その分ほかの脆弱性や不具合の修正も同じリリースに入れています。advisory の推奨は「A. 8.23.0 に上げる／B. 手元の版にパッチを当てる／C. HTTP/2 を使わない」の 3 つです。8.20.x 系は 8.20.2 以降、8.16.x 系は 8.16.2 以降、8.14.x 系は 8.14.3 以降が影響を受けない版とされています。

再発防止について、作者は「ここ数年、ハンドルを直接指す内部ポインタを減らし、代わりに転送の識別子を持って必要なときに引く方式に移してきた。少し遅いが、今回のような論理の誤りに強い」と書いています。そのうえで、curl を別の言語で書き直すことはせず、C のまま「磨き、改善し、作り直し続ける」という立場も改めて示しました。

📋 5. 残り 23 件の見取り図

24 件を性質で分けると、次のようになります（curl.se の各 advisory の題名と説明から筆者が分類）。

分類 件数 主な例
HTTP/2 の解放後使用（High） 1 92392
認証情報が意図しない相手に渡る 6 プロキシにホストの認証情報（86414）／Negotiate（Kerberos）の取り違え 3 件／.netrc のパスワードが URL に（94266）／SigV4 の残り（86409）
接続の再利用の取り違え 3 送信元インターフェース（107929）／Schannel の自動クライアント証明書（86415）／FTP のクライアント証明書（86411）
Cookie・HSTS の保存 4 サーバーの Cookie で cookie jar が消える・読み込みが止まる／HSTS のエントリが消える
証明書・ホスト鍵の検証 3 wolfSSL の公開鍵ピン留め（87866）／SSH の known hosts（87865）／SFTP・SCP へのリダイレクト（86410）
メモリ・再帰 3 GnuTLS＋WebSocket の読み過ぎ（107928）／FTP ワイルドカードの解放後使用（92388）／MIME の深い再帰（92391）
その他のプロトコル・ツール 4 FTP など応答の欠落で終わらないループ（92387）／TFTP（92389）／-J の上書き防止（92390）／IMAP APPEND（87864）

全体を見ると、「認証情報や接続を、本来の相手とは別の相手に使ってしまう」系統が多いのが目立ちます。代表的なものを 3 つ見ておきます。

  • CVE-2026-86414（プロキシにホストの認証情報）: HTTP プロキシが CONNECT の要求に、本来の 407 Proxy-Authenticate ではなく 401 WWW-Authenticate で答えると、libcurl が接続先サイト用の認証情報（Basic のパスワードや Negotiate／Kerberos のチケット）をプロキシに送ってしまう。影響する版は 7.10.8 から 8.22.0 まで
  • CVE-2026-94266（.netrc のパスワードが URL に）: .netrc から認証情報を読んだとき、CURLINFO_EFFECTIVE_URL（コマンドでは --write-out '%{url_effective}'）が返す URL にパスワードが入ってしまう。ログに URL を書き出しているスクリプトでは、パスワードがログに残りうる
  • CVE-2026-92388（FTP ワイルドカードの解放後使用）: FTP のワイルドカード LIST が失敗したとき、後片付けの経路が漏れて、ハンドルの再利用や複製で解放後使用や型の取り違えにつながる。CURLOPT_FTP_WILDCARD を有効にしたときだけ起きる

このうち 3 件（86409・86411・87864）は 8.22.0 ですでに直っており、今回あわせて公表されたものです。一方、Negotiate の 3 件（94265・86413・87861）と 86411・86415 は 8.21.0 で入った変更が原因で、影響する版は 8.21.0 以降に限られます。

SMB の削除と CURL_GLOBAL_WIN32 の改名

8.23.0 の変更点は 4 つで、うち 2 つは使い方に関わります。

  • SMB(S) のサポートを削除: curl も libcurl も smb://／smbs:// を扱わなくなりました。スクリプトで SMB の共有を curl 経由で読み書きしていた場合は、8.23.0 に上げると動かなくなります
  • CURL_GLOBAL_WIN32 を非推奨にし、CURL_GLOBAL_WINSOCK へ: curl_global_init() に渡すフラグの名前を、中身を正しく表す名前に変えたものです。Windows 向けに libcurl を組み込んだコードで旧名を使っていれば、新しい名前に置き換えておきます

ほかに、--no-clobber が番号を拡張子の前に入れるようになり、試す番号も 9999 までに増えました。不具合の修正は 281 件です。

🤖 6. Aisle の監査 ── curl にとって 5 回目の外部監査で 35 件

同じ 10月14日、作者は Aisle の監査報告を curl のサイトで公開しました。作者によると、この 1 年ほど Aisle の複数のエンジニアが AI を使ったツールを curl のソースコードに向け、その結果は公開済みの curl の脆弱性と CVE 番号で 35 件にのぼります。これで curl の外部の公式監査は 5 回目です。

作者はこの協力関係を高く評価しています。

  • Aisle は、これまでのどのグループや個人よりも多くの CVE を curl で見つけた。Aisle の社員はすでに curl に数十のコミットを書いている
  • 「熟練した人間のチームに裏打ちされた、詳細で正確な指摘が大量にある」ことで、これまでにない速さで脆弱性を見つけて直せるようになった
  • curl のソースコードは毎日、数えきれない人間と AI が脆弱性を探して調べている。誰が何人かは分からない。curl のチーム自身も、手に入る最良のツールで調べ続けている

今回の 24 件の発見者を advisory のクレジットで数えると、次のとおりです。

発見者 件数
Aisle Research の研究者 2 名 18
Anthropic（Luna with Claude） 2（High の 92392 と GnuTLS＋WebSocket の 107928）
その他の個人 4

Aisle 自身のブログの題名も「One AISLE curl Audit Produced 24 CVEs. 18 Ship Today」で、数が合います。作者は High の 1 件について「Anthropic の新しい OSS Scanner で見つかった。おそらく同社の AI モデルが使われている」と書いています。AI の支援で見つかった指摘を、人間のチームが確かめて報告し、プロジェクトが短い周期で直して配る。今回のリリースは、その流れが回った結果です。

🖥️ 7. 自分の curl を確かめる

curl -V の読み方

確認は curl -V（大文字の V）だけで足ります。見るのは 3 か所です。

  • 1 行目: curl と libcurl の版、TLS ライブラリ（Schannel・OpenSSL・GnuTLS・wolfSSL など）
  • Protocols: 扱えるプロトコル。smb があれば 8.23.0 より前の版
  • Features: 機能の一覧。HTTP2 があるかどうかが High の 1 件の分かれ目

Windows の PowerShell 5.1 では curl が Invoke-WebRequest の別名になっているので、curl.exe -V と .exe を付けて呼びます。PC に curl が何個あるかは、コマンドプロンプトの where curl で一覧できます。

筆者の PC での例（2026年10月19日）

どこの curl 版と TLS HTTP2 メモ
Windows 同梱（C:\Windows\System32） 8.21.0・Schannel なし Kerberos・SPNEGO・SSPI あり
Git for Windows 2.46.0 同梱 8.9.0・Schannel なし smb あり・Git が古い
WSL の Ubuntu 22.04 7.81.0（Ubuntu 版 1ubuntu1.25）・OpenSSL あり ディストロの版番号で判断

Raspberry Pi は、OS が何をベースにしているかで見る先が変わります。Raspberry Pi OS なら Debian のセキュリティ情報、Ubuntu なら Ubuntu のセキュリティ情報です（下の「更新の仕方」）。

Windows 同梱の 8.21.0 は、版の数字だけなら 92392 の範囲（8.12.0〜8.22.0）に入ります。ただし Features に HTTP2 がなく、advisory の回避策 C「HTTP/2 を使わない」と同じ状態です。一方で、Schannel 限定の 86415 や、Negotiate の 3 件は 8.21.0 で入った変更が原因なので、自動クライアント証明書や Negotiate 認証を使っている場合は範囲に入りえます。Microsoft が同梱の curl をいつ、どの版に更新するかは、2026年10月20日時点で確認できていません。

どの CVE が自分に当たるか

手元の状況 見るべき CVE
8.12.0〜8.22.0 で、Features に HTTP2 がある 92392（High）
8.21.0〜8.22.0 で、Negotiate（--negotiate）の認証を使う 94265・86413・87861
Windows（Schannel）で自動クライアント証明書を使う 86415
HTTP プロキシ経由で、接続先にも認証が要る 86414
.netrc を使い、%{url_effective} をログに書く 94266
TLS が wolfSSL／GnuTLS（1 行目で分かる） 87866／107928
SFTP・SCP へのリダイレクトを許している 86410

どれにも当てはまらなくても、Low の修正の多くは古い版から長く入っていた問題です。更新できるものは 8.23.0（またはディストロの修正版）に上げておくのが基本です。

更新の仕方

  • Windows 同梱: 利用者が個別に差し替えるものではなく、Windows Update での配布を待つ形になります。急ぐ場合は、curl の公式サイトの Windows 版を別に置き、使うほうを明示して呼びます
  • Git for Windows: Git の更新で同梱の curl も入れ替わります。リリースノートでは v2.56.0.windows.1（9月28日）が「cURL v8.22.0 を同梱」と書いており、2026年10月20日時点の最新 v2.56.0.windows.2（10月5日）も 8.23.0 の公開より前です。8.23.0 を同梱した版が出たら更新します
  • Ubuntu: USN-8927-1（10月14日）で 26.04（resolute）に curl 8.18.0-1ubuntu2.8 が、USN-8927-2（10月19日）で 26.10（stonking）に 8.20.0-2ubuntu11.1 が出ています。22.04・24.04 向けには USN-8932-1（10月14日） があり、86414 を含む 9 件の修正として 22.04（jammy）に 7.81.0-1ubuntu1.30、24.04（noble）に 8.5.0-2ubuntu10.16 が出ています。ただし CVE-2026-86414 の個別ページは2026年10月20日時点でも 22.04・24.04 を「needed（修正待ち）」と表示しており、USN と表記が揃っていません。92392 については、24.04（noble）以前は「該当コードなし（not-affected）」です。まずは sudo apt update && apt list --upgradable 2>/dev/null | grep curl で、USN の版まで上がっているかを見ます
  • Debian／Raspberry Pi OS: 92392 は、trixie（Debian 13）が DSA-6558-1 の 8.14.1-2+deb13u7 で修正済み、bookworm（Debian 12）は該当コードなしです。apt policy curl libcurl4t64 で入っている版を見て、それより古ければ sudo apt update && sudo apt full-upgrade
  • アプリに同梱された libcurl: advisory が毎回書いているとおり、「libcurl は多くのアプリに使われているが、そうと明示されているとは限らない」。アプリが自前で libcurl を抱えている場合は、そのアプリの更新を待つしかありません。組み込み機器のファームウェアに libcurl が入っている場合も同じで、Yocto や Buildroot で作ったイメージなら、レシピの curl の版を確かめておきます

🔧 技術者の所感

📌 筆者の見方

この欄は筆者の意見です。今回の High の 1 件を読んで印象に残ったのは、条件の一つひとつが「正しい動き」だったことです。フロー制御で止める、ストリームを打ち切る、終わった easy handle を解放する。どれも仕様どおりで、組み合わせたときにだけ穴が開く。マイコンでも、割り込みとメインループが同じバッファを扱うとき、片方が「もう使わない」と判断した後に、もう片方がまだ参照している、という形のバグはよく見ます。作者が書いた「ポインタを持ち回すのをやめて、識別子で毎回引く」という対策は、少し遅くても寿命の管理を一か所に集める考え方で、規模を問わず使える知恵だと感じました。

もう一つは、量と速さです。同じ週には、Linux カーネルのホスト側の穴（PwnEscape）が AI の支援で見つかり、OpenSSH 10.6 のリリースノートも、AI を使った報告が大量に届いているので、しばらくはリリースの頻度を上げると書いていました。curl も今回、報告の数時間後に確認し、リリースを 2 週間早めています。見つかる速さが上がった分、直して配る側も速くなっている。利用者の側でできるのは、curl -V で手元の curl を把握し、届いた修正をすぐ入れられる状態にしておくことだと思います。

✅ まとめ

  • curl 8.23.0（10月14日）は脆弱性 24 件を修正。High は CVE-2026-92392（HTTP/2 アップロード中の解放後使用・8.12.0〜8.22.0）の 1 件で、残り 23 件は Low
  • 92392 は RCE まで実証されたが、成立には悪意のあるサーバーへのアップロードと環境の細部の一致が要り、作者は「最もありそうな結果はクラッシュ」と見ている。回避策は HTTP/2 を使わないこと
  • 24 件のうち 18 件は Aisle の研究者、2 件は Anthropic が見つけた。Aisle の監査は curl で 5 回目、通算 35 件
  • SMB(S) のサポートは削除、CURL_GLOBAL_WIN32 は CURL_GLOBAL_WINSOCK へ

この記事で、自分の curl の版と機能から、どの CVE が当たるかを判定できるようになったはずです。次の一手は、PC・WSL・Raspberry Pi・CI のイメージで curl -V を一度ずつ打ち、HTTP2 ありで 8.12.0〜8.22.0 のものから順に更新することです。Windows 同梱版と Git for Windows の更新が出たら、本記事に追記します。

よくある質問（FAQ）

Q. Windows に最初から入っている curl は危ないですか？

A. 筆者の PC の Windows 同梱版は 8.21.0 で、版の数字は High の 92392 の範囲に入りますが、Features に HTTP2 がなく、advisory の回避策「HTTP/2 を使わない」と同じ状態です。Low の一部（Schannel の自動クライアント証明書・Negotiate 認証）は、その機能を使う場合に範囲に入りえます。Microsoft が同梱版をいつ更新するかは未確認です。

Q. curl コマンドを使っていなければ関係ありませんか？

A. libcurl はさまざまなアプリに組み込まれていて、advisory も「そうと明示されているとは限らない」と書いています。92392 は curl コマンドと libcurl の両方に影響します。アプリの更新情報も気にしておきます。

Q. 悪意のあるサーバーにさえつながなければ大丈夫ですか？

A. 92392 の成立には、被害者が悪意のあるサーバーへ HTTP/2 でアップロードすることが必要で、サーバー証明書も有効である必要があります。普段つなぐ相手が限られていれば可能性は下がりますが、リダイレクトなどで相手が変わることもあるので、更新しておくのが基本です。

Q. HTTP/2 を止めるにはどうすればいいですか？

A. curl コマンドなら --http1.1 を付けると HTTP/1.1 で通信します。libcurl を使うアプリなら CURLOPT_HTTP_VERSION で HTTP/1.1 を指定します。あくまで更新までのつなぎです。

Q. Ubuntu 24.04 や 22.04 は対象ですか？

A. 92392 については、Ubuntu は 24.04 以前を「該当コードなし」としています。86414 などの Low の一部は、USN-8932-1（10月14日）で 22.04 に 7.81.0-1ubuntu1.30、24.04 に 8.5.0-2ubuntu10.16 が出ています（CVE の個別ページは2026年10月20日時点でも「修正待ち」の表示で、USN と揃っていません）。まずその版まで更新しておきます。

Q. AI が見つけた脆弱性は信用できるのですか？

A. 今回の 24 件は、どれも curl のセキュリティチームが確認し、advisory として公表したものです。作者は Aisle について「熟練した人間のチームに裏打ちされた、詳細で正確な指摘」と評価しています。

関連記事

参考