Windows の管理者権限プロセスは ChatGPT / Codex の Computer Use から操作できない — UIPI が引く壁の位置

Windows で [ChatGPT デスクトップアプリ](https://chatgpt.com/download/) の Computer Use を AI テスターとして使い始めると、管理者権限で起動したプロセスのウィンドウに対しては、クリックもキー入力も何ひとつ届かないという壁にぶつかります。原因は Windows の Mandatory Integrity Control（MIC）と UIPI（User Interface Privilege Isolation）で、標準ユーザー整合レベルのプロセスから高整合レベルのウィンドウへ入力を送ることが OS 側で禁止されているためです。この記事では、境界の位置、影響を受けるツールの範囲、実務で取り得る回避策と、そこから見えてくる AI テスターの配置制約を、公式ドキュメントで確認できる範囲で整理します。

Cua Driver 0.26.1 の Computer Use 内部実装を読む — ウィンドウへの宛先固定と、操作結果・事後条件検証の分離

先日、Hermes Agent と Open Interpreter の Computer Use 内部実装を続けて読みました。どちらも操作そのものは外部の cua-driver に委譲していたので、次の関心は「その委譲先で何が起きているのか」でした。この記事は trycua/cua モノレポの commit b4e3caec に固定して、Cua Driver 0.26.1 の内部実装をコードリーディングしたノートです。MCP・CLI・SDK からの 1 回の要求が、対象ウィンドウと要素を確定し、OS の入力 API へ届き、公開 ActionResult と verify_state に射影されるまでを、native dispatch・WindowTargetGuard・element_token・macOS の ScreenCaptureKit・Windows の WGC / PrintWindow・Linux の X11 / Wayland・contract projection・permission mode の 3 層、という 8 つの分かれ道に沿って追いました。

Open Interpreter rust-v0.0.42 の Computer Use 内部実装を読む — QA スキルから cua-driver CLI へ至る経路

先日 Hermes Agent v2026.9.7 の Computer Use 内部実装を読みました。同じ cua-driver を使うと明記されている Open Interpreter は、エージェント側の実装がどこまで似ていて、どこが違うのか。この記事は Git tag rust-v0.0.42 に固定して、モデルの 1 回の QA 依頼が qa-testing スキルの読み込みを経由して cua-driver CLI と Cua daemon に届き、結果と画像がモデルへ戻るまでを追ったコードリーディングノートです。バイナリ埋め込み QA スキルの配布、外部 CLI への責務委譲、汎用コマンド実行と承認、view_image による画像経路、Cua permission mode と OS 権限の 3 層、OI の tag だけでは Cua 版が固定されない再現性の問題、という 6 つの分かれ道を、該当ソースにリンクしながら書き残しました。

Hermes Agent v2026.9.7 の Computer Use 内部実装を読む — capture の宛先固定と background-first の verify → escalate

先日 macOS で有効化した Hermes Agent の computer_use ツールセットについて、コードを読むほど「単純な VLM の座標クリック」ではないことが見えてきました。この記事は Git tag v2026.9.7 に固定して、モデルの 1 つの tool 呼び出しが cua-driver の MCP サーバーへ届いて OS 操作になり、結果が verdict と再 capture として戻ってくるまでを追ったコードリーディングノートです。capture の宛先固定、background-first の verify → escalate、MCP timeout での書き込み系不再送、画像を返す 3 経路、そして Hermes 側と cua-driver 側の別レイヤーの承認、という 5 つの設計上の分かれ道を、該当ソースにリンクしながら書き残しています。

AI エージェントに QA テスターを任せて開発サイクルを短縮する — OpenAI GPT-6 Astra と Computer Use を軸にした設計メモ

OpenAI の GPT-6 Astra と Computer Use を組み合わせて AI エージェントに QA テスターを任せる設計を 2026 年 9 月時点で整理したメモです。決定的な E2E スイートと探索的な AI テスターは目的も回すタイミングも異なり、開発者のローカル環境（Codex と ChatGPT デスクトップアプリの Computer Use を併用）・PR ごとの探索テスト・夜間の広域スイート・手動 QA の一次巡回の差し替えという 4 つの配置に切り分けると開発サイクルが素直に短縮できます。任せる範囲・任せない範囲、記録と再現性、非決定性への対処、機密データとコストの見立てまで、公式ドキュメントと OSS 実装から読み取れる設計方針を中心に整理しました。

Hermes Agent の Computer Use を macOS で有効化した記録 — /Applications 書き込みと TCC 権限で詰まった 7 つのポイント

先日書いた選定メモの続きで、Hermes Agent v0.21.1 の computer_use ツールセットを macOS Tahoe (26.6) の実機で有効化しました。インストール自体は hermes computer-use install の 1 コマンドなのですが、cua-driver が /Applications への .app 配置を必須にしていること、Jamf 管理端末で非 admin だったこと、TCC 権限がプロセスの bundle identity に紐づくことなどが重なり、途中で 7 回詰まりました。この記事は各つまずきの症状と原因、そして次に同じ環境を組む人のために残しておくべき手順を、実際に出たログ付きでまとめたものです。

macOS と Windows 両対応の Computer Use エージェントを比較検討したメモ — Hermes Agent・cua-driver を軸にした 2026 年 9 月時点の選定

macOS と Windows の両方でネイティブアプリまで操作できる Computer Use エージェントを 2026 年 9 月時点で比較検討したメモです。両 OS で OS 全体を操作できる公式アプリは ChatGPT デスクトップアプリと Claude デスクトップアプリの 2 択で、OSS では Nous Research の Hermes Agent と trycua の cua-driver を核に、UI-TARS・Agent S・Open Interpreter が有力候補になります。背景操作の「no-foreground contract」の実際の運用範囲、macOS の TCC 権限と AX API、Windows の UIPI・Session 0 制約、マルチモニター・日本語 IME の制約まで、機能表に載らない選定ポイントを中心に整理しました。

同名の先行 OSS に気づかず作ってしまったので hermes-talaria へリネームしました

自分がメンテしている OSS の名前 oh-my-hermes が、約 1.3k stars を集める先行リポジトリと衝突していることに後から気づきました。紛らわしいだけなので hermes-talaria へ改名し、ついでに拡張機能の名前空間 prefix omh- を ht- に切り替えました。今は自分しか利用者がいないので、破壊的変更でも問題ありません。改名先については GitHub 検索で先行の star 数を確認しています。

Hermes Agent で Claude に切り替えたら HTTP 400 が出た — サードパーティアプリと extra usage の課金枠

Hermes Agent のモデルを OpenAI から Claude に切り替えたところ、`HTTP 400: Third-party apps now draw from your extra usage, not your plan limits.` が返ってきました。エラー文言はサードパーティアプリが別枠の extra usage クレジットを消費すると案内しますが、Anthropic 公式ヘルプは同じ切り替えを「一時停止」中と明記しており、案内と実挙動がずれています。エラーの読み方と、実際にどう回避したかをまとめます。

Electron 向け暗号化 SQLite ライブラリを実測する — better-sqlite3-multiple-ciphers と @journeyapps/sqlcipher を macOS・Windows で動かす

前記事で挙げた Electron 向け暗号化 SQLite ライブラリの候補を、実際にプロトタイピングして macOS と Windows で動かしてみました。better-sqlite3-multiple-ciphers はプリビルドのまま両 OS で動き、@journeyapps/sqlcipher は macOS では動きますが v6.0.0 で Windows サポートを公式に廃止しているため、vcpkg で自前 OpenSSL を仕込む回避策まで検証しています。app-distribution-recipes リポジトリ上のレシピと 4 本の PR をベースに、実測で見えた挙動を整理します。

Electron 向け暗号化 SQLite ライブラリを比較する — better-sqlite3-multiple-ciphers を本命に据える理由

Electron デスクトップアプリでローカル SQLite を Data at Rest として暗号化したいときに、どのライブラリを選ぶべきかを整理する。better-sqlite3-multiple-ciphers・@journeyapps/sqlcipher・@signalapp/sqlcipher・SQLite SEE・Realm を、暗号方式・N-API プリビルドの有無・ライセンス・macOS 署名や公証との相性で比較し、なぜ本命が better-sqlite3-multiple-ciphers なのかを解説する。

「ゆるテク なんかそれっぽい勉強会 2026.08」に登壇しました — Hermes Agent を活用した自律型開発

熊本で開催された「ゆるテク なんかそれっぽい勉強会 2026.08」に登壇し、Hermes Agent を活用した自律型開発について話しました。自律型開発の主役はコード生成ではなく開発ループの自動化であり、人間はゴール・制約・評価関数を、AI はループを回す役割分担で捉えると設計しやすい、というのが今回伝えたかった軸です。あわせて、他の登壇者のお話への所感も残しておきます。

The Great Engineering Leader Career Break を新陳代謝と新しい CTO 像で読む — Pragmatic Engineer の 6 つの理由への現場からの応答

Pragmatic Engineer の Headed for the Exit は、CTO や VPE が high-status なポジションから相次いで降りている現象を 10 の理由で解剖しました。私はこの記事に書かれていることは概ね理解できるという立場で、個々人の生き方の問題だと思っています。そのうえで、代表的な 6 つの理由に対して、新陳代謝と新しい CTO 像という 2 つの軸から現場の反応を書きます。

Epic の sub-issue に `S-N-A` / `S-N-H` の通し番号 prefix を付けて AI エージェントと人間で開発を分担する

Epic issue を sub-issue に分割して開発を進めるとき、通し番号 `S-N` を 1 つの作業単位として扱い、AI エージェント（Claude Code や Codex など）担当分を `S-N-A`、人間担当分を `S-N-H` の別 sub-issue として並べています。1 つの作業に両方の手番が必要な場合は `S-N-A` と `S-N-H` を並べて立ててそれぞれ独立に close し、片方で完結する場合は対応する片方だけを立てます。以前は 1 つの sub-issue の中に AI エージェントに任せられるタスクと人間しかできないタスク（本番相当のクレデンシャル更新、外部連携先との調整、UX 上の判断など）がチェックリストとして混在しており、エージェントが自分でできる部分だけ埋めて PR を返した後、残りが拾われずに close できない sub-issue が積み上がっていました。sub-issue の粒度で担当を切り分け、通し番号 prefix でそれを示すことで、Epic の sub-issue 一覧を開いた時点で分担が読める状態に揃えています。実際の粒度、切り分けの目安、PR タイトルへの流し込みまで、この repo での経験からまとめます。

Forward-Deployed Engineering が SIer 語彙になる日 — EPAM の 2026 Q2 決算に Palantir 用語が現れた意味

EPAM Systems の 2026 Q2 決算資料で、CEO Balazs Fejes は自社を「next-generation forward-deployed engineering organization」と表現しました。もともと Palantir の職能名として使われてきた forward-deployed engineering というフレーズが、6 万人規模のグローバル IT サービス企業のポジショニングに採用されたのは象徴的です。FDE の起源、EPAM が採用した文脈、日本の受託開発にとっての意味を整理します。

セキュアSAMBA と主要オンラインストレージを比較検討したメモ — 課金モデルの損益分岐点と契約前に確認したい制約

セキュアSAMBA を主要オンラインストレージ 7 サービスと比較検討したメモです。容量課金とユーザー課金の損益分岐点はおおむね 28〜30 名で、2026 年 3 月にセキュアSAMBA の主力プランが 100GB・50 名・15,000 円から 300GB・人数無制限・25,000 円に改定されたこと、DirectCloud が 2026 年 9 月からユーザー課金の Team Business を出したこと、ISMAP 必須なら Box とクリプト便に絞られること、機能表では見えにくいセキュアSAMBA の制約（ブラウザ同時編集非対応、Mac サポート、全文検索終了、通信量・セッション上限）まで整理しています。

Excel と Google Sheets を行き来する表計算で、壊れにくい関数を選ぶ — XLOOKUP を SUMIF に置き換えて互換性を担保した話

ローカル環境では Excel で作業し、共有は Google Sheets で行うワークフローでは、関数の互換性が実務上のボトルネックになります。XLOOKUP が Google Sheets 側で壊れた実例から、SUMIF・INDEX と MATCH への置き換え、検算セルの入れ方まで含めて、壊れにくいシート設計を整理します。

curl 直叩きから Backlog CLI「bee」へ — AI エージェント連携をもう一段ラクにする

前回は AI エージェント（Claude Code・Codex・Hermes Agent）から Backlog REST API を叩くために API キーを発行する話を書きました。今回はその curl 直叩き運用を、Nulab 有志が開発した Backlog CLI「bee」に置き換えて、エージェント運用がどう良くなるかを共有します。gh の Backlog 版という位置づけです。

AI エージェントから Backlog を操作するために API キーを発行する

Claude Code・Codex・Hermes Agent といった AI エージェントから Backlog を操作するために、Backlog の API キーを発行して連携させました。実用レベルで動いたので構成を共有します。あわせて、API キーが平文でブラウザに表示されたままな点、権限を細かく設定できない点など、公式に改善してほしい 2 点も整理します。

JP_Stripes Connect 2026 のトークセッション「AIプロダクトの開発・課金のリアル」で登壇しました

2026 年 8 月 1 日、横浜の岩崎学園情報科学専門学校で開催された JP_Stripes Connect 2026 に現地参加し、トークセッション「AIプロダクトの開発・課金のリアル」に登壇しました。AI プロダクトの開発と、Stripe を中心とした従量課金・トークン課金まわりのリアルについてお話しした内容と、当日言及した URL 一覧をまとめます。

OSS 個人スポンサーを一時停止しました

OSS 個人スポンサーを一時停止しました。令和8年 熊本地震を受け、個人のリソースを OSS ではなく地元・熊本へアロケーションするための判断です。再開は 2027 年ごろを目安に考えています。

AWS サポートケースは英語より日本語のほうが早いかもしれない — Basic プランで SES Production Access の一次返信を 5 日待った話

Amazon SES の Production Access 申請を英語のケースで出したら 5 日間まったく返信が来ず、日本語で別ケースを立てて突破しました。Basic サポートで詰まったときにどう動くか、そこで得た「英語より日本語のほうが早いこともある」という現場の肌感覚を共有します。

GitHub で大容量バイナリを扱う — Git LFS と代替パターンを 10 GB / 100 GB / 1000 GB のスケール別に比較する

モデルファイル、ゲームアセット、ビルド成果物。GitHub で扱いたいバイナリのサイズは、プロジェクトが育つほど 10 GB → 100 GB → 1 TB とオーダーが変わっていきます。10 GB では十分現実的な Git LFS が、100 GB を超えるとストレージ・帯域の超過料金が負担になり、1 TB クラスではオブジェクトストレージ連携がほぼ必須になります。この記事では 2026 年 7 月時点の公式料金と制約を突き合わせて、スケール別にどの選択肢が生き残るかを整理します。

issue を投げると PR が返ってくる — Codex と Claude Code を往復させる Hermes Agent の自律ループスキル

AI にコードを書かせる時代に人間が一番時間をかけるべきなのは、コードでもレビューでもなく、そのループが回る基盤と、issue の plan です。issue URL 1 本から review-ready な PR までを自走させるスキルを実装して、その確信が強まりました。

PR レビューを Claude Code と Codex に同時にやらせる — Hermes Agent スキルで多モデルレビューを自動化する

1 つのモデルによるコードレビューは、そのモデルの盲点をそのまま引き継ぎます。ならば独立した複数のモデルに同じ PR を読ませて、重なった指摘だけを信じればよい。その運用を 1 コマンドに落とし込んだスキルの実装を追います。

反社・コンプライアンスチェック SaaS を比較検討したメモ — 情報源設計と課金モデルの罠

国内の反社・コンプライアンスチェック SaaS 6 サービスを CTO として比較検討したメモです。市場は 2025〜2026 年に大きく再編され、RoboRobo と SP RISK SEARCH は業務提携で SPRS という統合プラットフォームに寄りました。単純な機能表比較では見えにくい「情報源の設計思想」「課金の実質単位（名義単位）」「監査証跡と承認フロー」「海外対応の中身」の 4 論点に絞って、選定で見落としやすいポイントを整理しています。

既存プロダクトはまず Claude Fable 5 と GPT-5.6 Sol で高速にリファクタリングする

前記事の教訓は、そもそも自分が実害を出してから書いたものです。Loop Engineering を既存プロダクトに持ち込んでみて、2 週間で気づいたのは、判定基盤がない状態でループを回すと負債は 10 倍速で積み上がる、という当たり前でした。この記事はその後悔と、そこから戻って Claude Fable 5 で計画・GPT-5.6 Sol で実装、の軽い設定 2 モデル体制で高速に判定基盤を敷き直した実際の流れを書きます。

既存プロダクトに Loop Engineering をそのまま持ち込むと技術的負債が高速で積み上がる — まずリファクタリングで判定基盤を立て直す

前記事でソロプレナー的な新規プロダクトなら Loop Engineering がそのまま効くと書きました。裏を返すと、既存プロダクトはそのまま効かないということです。効かないだけならまだよく、判定基盤が育っていないところで Loop Engineering を回すと、通ってしまうゲートの下で技術的負債が高速で増えます。この記事は、検出されない不具合の増加を避けるために先にやるべきことを整理します。

Loop Engineering はソロプレナー的な新規プロダクトで最も効く — ゼロから立ち上げて全設計を自分が把握しているとき

Loop Engineering は万能ではなく、効くリポジトリと効かないリポジトリがはっきり分かれる。分岐点は、仕様を持っているのが誰か、判定基盤が育っているか、そしてマージ判断まで含めて意思決定が一人に閉じているかです。ソロプレナー的な新規プロダクトは、この 3 つがそろう数少ない条件なので、Loop Engineering の設計思想がそのまま活きます。

Amazon WorkSpaces Personal を Simple AD で小規模に使う — 構成と費用と拡張パス

ブラウザと電子証明書を使う業務専用の Windows 端末として、少人数向けに Amazon WorkSpaces Personal を Simple AD で立ち上げた。2026-07-30 以降、Simple AD は新規顧客向けの提供を停止しており、既存顧客だけが引き続き使える状態になっている。この記事では、東京リージョンでの実費用、Simple AD で困ること、AWS Managed Microsoft AD や AD Connector を選ぶ判断軸、バックアップと復旧の限界までを、公式情報の出典付きで整理する。

Codex の Chrome 拡張で Codex にブラウザを操作させる — 本格運用してみた所感と Claude in Chrome との住み分け

5 か月前に書いた Claude in Chrome の記事の Codex 版です。2026 年 5 月 7 日にリリースされた Codex の Chrome 拡張は、Claude in Chrome とよく似た「サイドから拡張機能でブラウザを操る」路線を採りつつ、開発者ワークフロー寄りの機能（DevTools アクセス・Web アプリのテスト・タブ横断の context）を持たせています。2 か月あまり本格運用して分かった効き所と、Claude in Chrome との住み分けを実運用の目線で整理します。

AI コーディングで本番リリースする前にノンデベロッパーにも押さえてほしい 15 の観点

AI コーディングツールは「動くコード」を高速に量産できます。ただし、本番では負荷の増加や異常な入力、再試行にも対応する必要があります。ノンデベロッパーが AI に書かせたコードを世に出す前に、どこを見ればよいかを 15 項目に整理しました。

コーディングエージェントのモデル選びは機会コストで決める — Fable 5 Low・Codex 5.6 Sol Light を速度に振る理由

最近、Claude Code では Fable 5 を推論レベル Low、Codex では 5.6 Sol を推論レベル Light・速度レベル Fast と、意識して軽く速い設定をデフォルトにしています。今の高知能モデルは推論トークンを絞っても、ミスの傾向に大差がありません。だとすればレビュー工数は変わらず、効いてくるのはトークンコストより待ち時間、つまり機会コストです。機会コストは見えにくいけれど、人間がボトルネックである以上その支配は自明だ、という話です。

Gemini CLI は OSS であり続けるのか — Apache 2.0 のコードとバックエンド規約の二層で読む、Antigravity CLI 移行後の新規採用リスク

Google は Gemini CLI からクローズドソースの Antigravity CLI への移行を発表し、2026-06-18 に無償・個人向けのアクセスを遮断しました。しかし Gemini CLI のコード自体は Apache 2.0 のまま残り、リポジトリの更新も続いています。新規採用の可否は「コードのライセンス」と「バックエンドの利用規約」という二層に分けて読むと正しく判断できます。何が起きたのか、Apache 2.0 の取消不能性、サービス規約の可変性、ガバナンスの実態、移行に伴う技術的非互換、そして代替ツールと防御策までを 2026 年時点で整理します。

Windows コード署名を CI で回すコストを月間署名回数別に比較する — 大手アプリの実バイナリ検証から見えた 2026 年の現実

Windows のコード署名を CI で自動化するとき、SSL.com eSigner・DigiCert KeyLocker・Azure Key Vault + GlobalSign のどれを選ぶかで年額が数倍変わります。月 20 回で最安のサービスは、月 1,000 回では逆に高くつく。しかも大手ベンダーの実際の署名構成を osslsigncode で検証すると、値札を眺めているだけでは見えない「配布用インストーラーは再利用し、本体はリリースごとに署名する」という運用原則が浮かび上がってきます。2026 年時点の CI コスト比較と、他社の実バイナリから読み取れる運用の型を整理します。

per-machine な Windows アプリはどうやって静かに自動更新しているのか — Chrome・Slack・VS Code の実装から学ぶ 3 大パターン

per-user なら自動更新は素直に書けます。per-machine で UAC を表示せずに自動更新するには、標準ユーザーが書き込めない場所を更新する仕組みが必要です。Chrome・Slack・VS Code といった有名アプリが実際にどう解いているかを引き比べ、Omaha 型 SYSTEM サービス・MSIX プラットフォーム委譲・MDM 再配布という 3 大パターンに落として比較します。

macOS Keychain のエラー -25294（errSecNoSuchKeychain）— 証明書のインポート先を login にしたら直った

証明書を Keychain に取り込もうとしたら、エラー -25294 が出てインポートできない。errSecNoSuchKeychain、つまり「指定されたキーチェーンが見つからない」というこのエラーは、証明書そのものではなく、保存先のキーチェーン指定が原因であることがほとんどです。保存先を Local Items から login に選び直したら直った経験をもとに、原因と最短の直し方を整理します。

AI 時代の Developer Experience — 競争力のあるエンジニアであり続けてもらうために

Claude 研修の講師をしていたとき、参加者のエンジニアから「AI 時代の Developer Experience（DevEx）の向上についてどう考えますか」と問われ、その場で考えを答えました。この問いに、フルリモート組織の CTO として、あらためて正面から向き合います。従来の DevEx とは何だったのか、AI で何が変わったのか、環境をどう与えるか。目指すのは、転職しても「あの会社出身は優秀だ」と言われる、市場で競争力を持ち続けるエンジニアを育てることです。

進捗報告はもう人間から要らない — AI 時代に人間が語るべきは未来だけ

過去と現在の進捗は、コミット・PR・CI・オブザーバビリティといった成果物にすでに刻まれていて、AI エージェントに聞けば要約が返ってきます。だとすれば、人間がわざわざ進捗を報告する意味は薄れる。人間にしか持てない情報は、まだどこにも書かれていない「未来」の側にある。フルリモート組織を率いる CTO の立場から、進捗報告という慣習を解体し、会議とレビューを未来中心に組み替える設計を考えます。

Anthropic 公式スキル 17 種を概観する — anthropics/skills リポジトリで何ができるのか

Anthropic 公式の Agent Skills リポジトリ anthropics/skills には、2026 年 7 月時点で 17 個のスキルが収録されています。docx・pdf・pptx・xlsx のオフィスファイル操作から、algorithmic-art や frontend-design のデザイン、mcp-builder や skill-creator の開発拡張まで、各スキルの SKILL.md をサマリして 5 カテゴリで概観します。

Hermes Agent で context を使い切ったときの対処 — 中途半端は捨て、クリーンなセッションで作り直す

Hermes Agent で PR を作成してもらっている最中に「Context length exceeded. Cannot compress further.」で止まり、/compress も効かない。そんなときのトラブルシューティング Tips として、中途半端な変更は捨て、コミット済みの進捗と Issue からクリーンに作業をやり直し、PR を仕上げて Issue を close するまでの型を整理します。

AI ソロ開発の CI コストを gh-signoff で削る — ローカル CI とサインオフという選択肢

AI エージェントに実装させると PR とプッシュの回数が跳ね上がり、リモート CI の実行回数に応じて課金も増えていきます。gh-signoff はテストをローカルで走らせて自分で署名するという、身も蓋もないが理に適った解を提示します。

xxx.onmicrosoft.com のアドレスでメールを送受信する — ライセンスとメールボックスの仕組みを押さえる

Microsoft 365 テナントを作ると `user@contoso.onmicrosoft.com` のようなアドレスが自動で付きますが、そのアカウントでメールを送受信しようとすると受信すらできないことがあります。原因は、サインインできる Entra ID のアカウントと、メールを溜める Exchange Online のメールボックスが別物だからです。この記事では、なぜ既定で送受信できないのか、どのライセンスを用意して割り当てればよいのか、そして onmicrosoft.com から外部へ送るときに 2026 年から段階適用される送信上限までを、実際の管理手順に沿って整理します。

OV・EV コード署名証明書を日本から取得する — 法人・個人事業主・個人の資格と 2026 年の価格比較

「コード署名証明書はいくらか」の前に、「そもそも自分が取得できるのか」を確かめる必要があります。日本法人ならほぼどの CA でも取れて価格で選べますが、屋号なしの個人開発者は主要 CA で原則発行されず、Microsoft 自身のクラウド署名サービスは日本を地理的に除外しています。この記事は価格表だけでなく、申請主体と地域による取得資格を主軸に、日本法人・日本在住の個人がどの証明書をどう取得できるかを 2026 年時点で整理します。

Windows デスクトップアプリを日本法人が安全に配布する — コード署名・SmartScreen の現実（2026 年版）

「Windows アプリを配布したいが、セキュリティソフトに弾かれたくない」。この要件を日本法人が満たす最短経路は、実務上ほぼ二択に収束します。Microsoft Store に MSIX で出すか、CA 発行のコード署名証明書で署名したインストーラを自社サイトから配るか。ただし 2024 年以降の Windows では EV 証明書を買っても SmartScreen の即時バイパスはできず、Microsoft の安価なクラウド署名サービス Azure Trusted Signing は日本法人を対象外にしています。証明書選定から署名・配布・SmartScreen 評判の運用まで、2026 年時点の現実解を端から端まで組み立てます。

Checkmarx を OSS で代替する — SAST・SCA・IaC・シークレットを束ねる AppSec スタック設計

Checkmarx を 1 対 1 で置き換えられる単一の OSS は存在しません。現実的な答えは、機能カテゴリごとに専用の OSS スキャナーを配置し、DefectDojo のような管理基盤で束ねる疎結合なマルチエンジン構成です。SAST の Semgrep CE と Opengrep の分岐点、Trivy を軸にした SCA、Checkov・KICS による IaC、Gitleaks・TruffleHog のシークレット検出、DefectDojo による重複排除と Jira 連携までを 2026 年時点で整理し、レガシー言語やサプライチェーンリスクといった代替の限界も併せて押さえます。

DAST の OSS ツールを比較する — ZAP・Nuclei・Wapiti・Nikto を DevSecOps パイプラインに束ねる

DAST（動的アプリケーションセキュリティテスト）は、稼働中のアプリを外部から擬似攻撃し、SAST や SCA では捉えられないランタイム固有の脆弱性を炙り出す手法です。OSS の DAST は「1 本で全部」から「軽量ツールを役割分担」へと移行しました。総合力の ZAP、テンプレート駆動の Nuclei、軽量 CLI の Wapiti、サーバ露出確認の Nikto を軸に据え、SQLi 特化の sqlmap、XSS 特化の Dalfox、無料だが OSS ではない Dastardly・StackHawk まで、2026 年時点の選定基準と、SPA・API 対応、CI/CD への段階的統合、誤検知チューニングの実務を整理します。

配布 CLI 成果物を Sigstore cosign で keyless 署名する — GitHub Actions OIDC・bundle 検証・改ざんテストの設計

out-of-band 配布の弱点は、受け取った成果物が「本当にあの組織のワークフローから出たもので、途中で書き換わっていない」ことを誰も確かめられない点にあります。Sigstore cosign の keyless 署名なら、長期保管する署名鍵を持たずに、GitHub Actions の OIDC 身元で成果物に署名できます。Fulcio が短命証明書を発行し、署名イベントは透明性ログに残る。検証側は certificate identity と OIDC issuer を pin することで「このリポジトリのこのワークフローが署名した」ことまで確かめられます。npm の .tgz と Google ドライブの zip の両方に署名し、改ざんテストで verify が確実に落ちることを CI に組み込んだレシピを、端から端まで組み立てます。

npm 公開を Trusted Publishing で多層防御する — トークンレス OIDC・ステージ公開・PR マージ起点リリースの設計

2025-2026 年の npm サプライチェーン攻撃を受けて、長期トークンによる公開はもはや既定の選択肢ではありません。GitHub Actions の OIDC を使う Trusted Publishing で publish secret をゼロにし、CI はステージ公開までしかできないように倒し、live 昇格は npm の MFA を要する別操作に分ける。さらに release Environment を PR マージ ref に絞り、リリース PR の生成自体も自動化する。リポジトリ書き込み権限ひとつでは live な npm パッケージを作れない多層防御を、実際に動くレシピとして組み立てます。

npm 製 CLI を Google ドライブで限定配布する — 自己完結 zip をクラウドストレージで共有するレシピ

レジストリを立てるほどではないが、ソースをそのまま渡すのも避けたい。そんなとき、npm 製 CLI を 1 つの自己完結 zip に固めて Google ドライブの共有リンクで配る、という素朴な配布方法があります。npm pack で作った tarball と INSTALL.md を zip にまとめ、リンク共有またはメール制限共有で限定公開し、ブラウザで人が取得してインストールするまでを、実際に動くレシピとして組み立てます。