[アップデート] Amazon Quick の Research（研究）が PowerPoint や Excel ファイル出力をサポートしたので試してみました

• URL: https://dev.classmethod.jp/articles/20250626-amazon-quick-new-research
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: Amazon Quick の Research（研究）機能が PowerPoint（.pptx）および Excel（.xlsx）形式でのファイル出力に対応したことを東京リージョン（ap-northeast-1）で確認した記事。プロンプトでファイル形式を明示的に指定すると対応形式で出力され、研究一覧画面にアーティファクト列（PPT/Excel アイコン）が追加された。生成所要時間は標準レポート約 4 分に対し Excel 約 10 分、PowerPoint 約 13 分。

詳細

著者はクラスメソッドクラウド事業本部の石川氏。顧客へのデモ中に Amazon Quick の Research（研究）機能が PowerPoint・Excel 出力に対応していることを発見し、東京リージョン（ap-northeast-1）で検証した記事。

Amazon Quick は自然言語対話で調査・分析・資料作成を支援する AI エージェント型ワークスペース。Research（研究）はプロンプトから調査計画を立て、Web やスペース登録データを根拠として収集し、出典付きレポートを自動生成する機能で、従来は画面表示・PDF・Word が中心だった。

今回確認された変更点: Research の成果物として PowerPoint（.pptx）・Excel（.xlsx）形式のファイルが出力可能になった。研究一覧画面に「アーティファクト」列が追加され PPT/Excel アイコンで識別できる。研究モードは「高速（5〜10 分）」と「詳細（20〜30 分）」の 2 種類があり、PowerPoint・Excel 出力は「より時間がかかります」と注記される。

検証結果（北海道大学の学部に関するレポート）: 形式指定なし → 約 4 分で画面表示レポート（スペース内容によっては自動で Excel 出力される場合があり、その際は従来フォーマットへ戻せない）。Excel 指定 → 約 10 分、6 シート構成（大学概要など）で日本語本文だが Executive Summary が英語になった。PowerPoint 指定 → 約 13 分、12 ページのスライドでタイトル・概要・学部紹介・入試制度等を含む。

ドキュメント・ビジュアル作成機能自体は 2026 年 4 月発表の「document and visual creation」として案内されており、今回は Research の出力でも同様に利用できることを確認した形。

非エンジニアの私がChromeの拡張機能を使ってKoTの機能追加をやってみた

• URL: https://dev.classmethod.jp/articles/20260617_chrome_application
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: 非エンジニアの社員が Claude（Sonnet 4.6）を活用し、勤怠管理システム KoT（King Of Time）向けの Chrome 拡張機能を自作した体験記。日々の労働基準時間との差分と月累計を表示する機能を、プロンプトによるコード生成とエラー対話を繰り返して実現した。専門知識がなくても AI と対話しながら小さな改善ができることを示す実例。

詳細

著者はクラスメソッド製造ビジネステクノロジー部の細見氏。所属会社では 5:00〜22:00 のコアタイムなしフレックス勤務を試行中で、勤怠管理システム KoT（King Of Time）に日次の労働基準時間（8時間）との差分表示と月中累計残業時間の機能が存在しないことが開発の動機。

Claude Sonnet 4.6 に相談し、manifest.json・content.js・style.css の 3 ファイル構成の Chrome 拡張機能コードを生成してもらった。実装上は Content Script で KoT のページ DOM を操作し、テーブル右端に差分列と月計行を追加する手法をとる。

開発中に「DOM 操作」の意味が分からず躓く、エラーメッセージのスクリーンショットを Claude に投げて対処法を確認する、VS Code がインストールされていないため別ファイル保存方法を再確認する、拡張機能インストール後も KoT 画面に反映されないためデバッグを繰り返す、といった試行錯誤が記録されている。Sonnet 4.6 が途中でファイル名の問題を指摘する前に別の解決策を提示するなど、モデルの回答精度の揺れも具体的に言及。最終的に KoT の画面上に差分列と月計が表示されることを確認した。記事末尾では社内 IT 部門への事前確認・承認を推奨している。

Claude Code v2.1.187〜v2.1.191 の主要アップデート

• URL: https://dev.classmethod.jp/articles/20260625-cc-updates-v2-1-191
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: Claude Code v2.1.187〜v2.1.191（2026-06-23〜24リリース）の主要アップデートをまとめた記事。サンドボックス内コマンドからの認証情報読み取りをブロックする sandbox.credentials 設定の追加、/clear 実行前まで会話を巻き戻せる /rewind の強化、ストリーミング応答中の CPU 使用率約 37% 削減が主な変更点。hooks のカンマ区切りマッチャー不発や停止バックグラウンドエージェントの復活など実運用に影響する不具合も解消された。破壊的変更・非推奨は含まれない。

詳細

対象バージョンは v2.1.187（2026-06-23）、v2.1.190（2026-06-24）、v2.1.191（2026-06-24）の 3 本。v2.1.188/189 は npm に存在せず、v2.1.190 は CHANGELOG が「Bug fixes and reliability improvements」のみで個別変更の内訳は非公開。

新機能として sandbox.credentials 設定が追加され、サンドボックス内コマンドが認証情報ファイルやシークレット環境変数を読み取れないようブロックできる（v2.1.187）。/rewind が /clear 実行前の会話状態まで巻き戻しに対応し、タスク区切りで /clear した後でも以前の作業に戻れるようになった（v2.1.191）。組織レベルのモデル制限がモデルピッカー・–model・/model・ANTHROPIC_MODEL に反映され、制限されたモデル選択時に警告メッセージを表示（v2.1.187）。フルスクリーンモードで権限プロンプトや /model・/config などのセレクトメニューをマウスクリック選択できるようになった（v2.1.187）。

パフォーマンス改善として、テキスト更新を 100ms 単位にまとめる（coalescing）ことでストリーミング応答中の CPU 使用率を約 37% 削減（v2.1.191）。ターミナル出力キャッシュに起因する長時間セッションでのメモリ増加も抑制（v2.1.191）。

修正の主要事項: カンマ区切り（“Bash,PowerShell” 形式）マッチャーを持つ hooks が無警告で発火しない不具合（v2.1.191）、停止したバックグラウンドエージェントが復活する不具合（v2.1.191）、リモート MCP ツール呼び出しが 5 分ハングする不具合（v2.1.187 / タイムアウトは CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT で上書き可）、構造化出力（–json-schema / workflow）でモデルが StructuredOutput を無限再呼び出しする不具合（v2.1.187）、VSCode 拡張が大規模セッション再開時に無応答になる不具合（v2.1.187）、韓国語・CJK 貼り付け時の文字化け（v2.1.187）、/permissions で承認が黙って破棄される問題（v2.1.191）。

MCP 関連では capability discovery（tools/list・prompts/list・resources/list）が一時的なネットワークエラー時に短いバックオフで再試行（v2.1.191）、MCP OAuth の discovery とトークンリクエストが一時的エラー後に 1 回再試行しヘッドレス環境ではブラウザポップアップをスキップ（v2.1.191）、HTTP 404 エラー時に対象 URL を表示するメッセージ改善（v2.1.191）なども含まれる。破壊的変更・非推奨はこの範囲に存在しない。

Claude Code v2.1.192〜v2.1.193 の主要アップデート

• URL: https://dev.classmethod.jp/articles/20260626-cc-updates-v2-1-193
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: Claude Code v2.1.193（2026年6月25日）は auto-mode の安全性・可視性強化とバックグラウンドエージェント周りの不具合解消が中心のリリース。全 Bash/PowerShell コマンドを auto-mode 分類器に通す autoMode.classifyAllShell 設定の追加、拒否理由のトランスクリプト表示、bash モードのライブファイルパス補完が新機能として加わった。OpenTelemetry で OTEL_LOG_USER_PROMPTS=1 を設定済みの環境はアップグレード後に応答内容もログされ始める破壊的変更があり、従来通りにするには OTEL_LOG_ASSISTANT_RESPONSES=0 を明示する必要がある。

詳細

Claude Code v2.1.193 は 2026年6月25日公開。v2.1.192 は npm・CHANGELOG いずれにも存在しない欠番のため実質的には v2.1.191 からの変更として扱う。変更件数は15件。

新機能の詳細:

• autoMode.classifyAllShell: 従来は arbitrary-code-execution パターンのみが分類対象だったが、この設定を有効にすると全 Bash/PowerShell コマンドを auto-mode 分類器に通すゲートを設けられる
• auto-mode 拒否理由の可視化: 拒否理由がトランスクリプト・拒否トースト・/permissions の最近の拒否一覧に表示されるようになった
• bash モード（!）でのライブファイルパス補完が追加
• MCP サーバーが認証を必要とする場合に起動時の通知で /mcp を案内するようになった
• バックグラウンドシェルのメモリ自動回収（アイドルシェルをメモリ逼迫時に自動 reap）。CLAUDE_CODE_DISABLE_BG_SHELL_PRESSURE_REAP=1 で無効化可能

修正された主な不具合:

• メインターンをバックグラウンド化すると general-purpose (resumed) というサブエージェントが生成される問題
• バックグラウンド化（←←）が「N background tasks would be abandoned」と誤表示してキャンセルしてしまう問題
• ピン留めしたバックグラウンドエージェントが自動更新のたびに「Continue from where you left off」を再プロンプトされる問題

破壊的変更: OpenTelemetry に claude_code.assistant_response ログイベントが追加された。OTEL_LOG_USER_PROMPTS=1 設定済みの環境では、アップグレード後に OTEL_LOG_ASSISTANT_RESPONSES の値が未設定の場合 OTEL_LOG_USER_PROMPTS の設定に従うため、意図せず応答内容もログされ始める。応答をログしたくない場合は明示的に OTEL_LOG_ASSISTANT_RESPONSES=0 を設定する必要がある。

AIがコードベースの40%を共同執筆した：4ヶ月155コミットの振り返り

• URL: https://dev.classmethod.jp/articles/ai-co-authored-40-percent-codebase-155-commits-retrospective
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: 4ヶ月・155コミットにわたる問い合わせ対応 RAG システム（Next.js + FastAPI + Amazon Bedrock Knowledge Bases）の開発記録。そのうち 62 件（40%）が Claude Code との共同執筆で、最初の1週間は Opus 4.6、その後は Sonnet 4.6 を使用した。フルスタック実装・デバッグ・リファクタリング・ドキュメント生成の各フェーズで AI が機能した一方、社内固有のドメイン知識・インフラ起因トラブルシューティング・微細な UI 調整は人間が担う役割として残った。.plans/ ディレクトリに 39 件の設計ドキュメントを蓄積し、AI との対話を意思決定ログとして残す運用も特徴的。

詳細

プロジェクト概要: 問い合わせ対応向け RAG システム（Next.js + FastAPI + Amazon Bedrock Knowledge Bases）をほぼ一人で開発。2026年3月12日〜6月18日（約14週間）、総コミット155件のうち 62件（40%）が Claude Code との共同執筆、76件（49%）が人間のみ、17件（11%）が Dependabot 自動更新。Python ソースコード約4,500行、TypeScript/TSX 約3,000行。設計ドキュメント 39ファイルを .plans/ に蓄積。

モデル変遷: 最初の1週間（2026-03-12〜03-18）は Claude Opus 4.6 で13コミット、以降は Claude Sonnet 4.6 で49コミット。Co-Authored-By トレーラーのモデル名で後から移行タイミングを追跡できた。~/.claude/settings.json の attribution.commit を空文字列に設定するとトレーラーを無効化できる。

AI が特に有効だった場面:

• フルスタック機能の初期実装（FastAPI エンドポイント・Pydantic モデル・React コンポーネント・SSE イベント・OpenAPI 仕様を1セッションで実装）
• 複合バグのデバッグ（SSE ストリーミング問題など一見1つに見えるバグが4つの独立した原因の複合だったケースで構造的分析が有効）
• boto3 → anthropic SDK 移行や Docker 基盤整備など「壊さずに置き換える」リファクタリング
• ドキュメント・設定ファイルの整備

AI が苦手だった場面:

• 社内固有のドメイン知識（カテゴリ ID ルールなど言語化して教える必要がある）
• VPN 経由 SOCKS プロキシ・EC2 インスタンスロール権限・nginx バッファリングなどインフラ起因のトラブルシューティング
• 感覚的な UI の微細調整（言語化コストが自分で直すより高い）

CLAUDE.md での AI スコープ制約例: 「明示的に要求されていない機能のコードを生成しない」「Pydantic モデルへのフィールド追加はルートとフロントエンド両方で参照されるものだけ」「実装後に呼び出し元がない関数はコミット前に削除する」といったルールを記述し、AI が「よかれと思って」余計な機能を追加する傾向を抑制した。

月別コミット分布: 3月24件（プロトタイプ・データパイプライン基盤）、4月55件（UI 刷新・SSE ストリーミング）、5月60件（構造化出力・SDK 移行・OpenAPI 整備）、6月16件（OpenSearch NextGen 移行・API Gateway 連携）。4月・5月の急増は AI 共同開発のテンポが掴めてきた時期と一致すると著者は述べている。

【セッションレポート】 Amazon Connect Customer で実現する進化したコンタクトセンター －エージェンティック AI が変える顧客体験－ [BIZ326]

• URL: https://dev.classmethod.jp/articles/aws-summit--2025-session-report-
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: AWS Summit Japan 2026 のセッション「Amazon Connect Customer で実現する進化したコンタクトセンター」（BIZ326）のレポート。Amazon Connect Customer は AI エージェントと人間のオペレーターが協働するコンタクトセンター向けサービスで、決定論的 AI・サポート AI・人間の適材適所な割り当てを主軸に据える。コンテキストをチャネルをまたいで引き継ぎ、測定・継続改善まで 1 プラットフォームで完結する設計が特徴。

詳細

著者はクラスメソッド AI 事業本部の竹口氏。AWS Summit Japan 2026 のセッション BIZ326「Amazon Connect Customer で実現する進化したコンタクトセンター」（スピーカー: AWS Japan ソリューションアーキテクト 三好雄登氏、レベル 300 Advanced）のレポート。

背景として AWS Japan のカスタマーサービスは 42 カ国 16 言語をカバーし、CX の悪化が顧客離脱を招く現状が示された。現行コンタクトセンターの課題はチャネル間での情報不整合、音声とチャット統合の維持コスト、オペレーターが複数システムを切り替える負担。

Amazon Connect Customer の主要設計方針は「適材適所な AI」で、手順が固定されたタスクには決定論的 AI、柔軟対応が必要なタスクにはサポート AI、共感・信頼が必要な場面では AI と人間のチームワークを割り当てる。

発表された主要イノベーションは 4 点: (1) AI による自律的アクション（注文履歴・配送ステータス・在庫確認を文脈から自律判断するデモ）、(2) AIと人間の適材適所な連携（チャット履歴・顧客概要・やり取りサマリをオペレーターと AI の両方に引き継ぎ、待機中に AI が購買傾向からレコメンデーションを行い、承認後に在庫確認・応答文章提案まで実施）、(3) データから顧客の好みを把握（ローコードの AI エージェント作成・ツール追加・MCP 連携・応答範囲コントロール、ジャーニー機能によるマルチチャネル・マルチステップ体験設計）、(4) 成果の測定と継続的な改善（全オペレーター・AI エージェントの処理状況を一元把握、E2E テストで本番前品質担保、マネージャー向けスコア評価メトリクスと AI アシスタント〈プレビュー〉）。

ローコード作成・MCP 連携・ジャーニー機能など具体的な機能名が複数登場し、Amazon Connect Customer の枠内でテスト・分析・評価・改善が完結する設計が強調された。

【非エンジニアのためのClaude/Claude Codeシリーズ】Claude＝業務効率化だけじゃない。営業1年目がロープレ練習相手として使ってみた

• URL: https://dev.classmethod.jp/articles/claude-business-usecase01
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: クラスメソッドの営業1年目社員がコードの知識なしで Claude をロープレの練習相手として活用した体験記。資料のテキストを貼り付けるだけで商談シミュレーションを開始でき、途中でストップして解説を求めながら反復練習できる点が有効だった。さらに HubSpot MCP 連携によって実際の顧客問い合わせ傾向を踏まえた高精度なロープレに発展させた事例を紹介している。

詳細

著者はクラスメソッド東日本営業本部の川崎氏（2026年5月入社、AI初心者・コード知識ゼロ）。Claude を使い始めて1〜2ヶ月での実践記録。

活用方法の概要: 営業資料の PDF や文書テキストをそのまま Claude に貼り付け、自分の立場と状況を伝えるだけでロープレを開始できた。準備の手間はほぼなく、ロープレ中に言葉に詰まった際に「ストップ」と入力して中断・解説を求め、理解してから再開するという反復練習が自分のペースでできる点が価値として挙げられている。

MCP 連携の応用: 社内 CRM の HubSpot と MCP 連携することで、Claude が過去の顧客対応から「よくいただくご質問の傾向」を集約し、それを踏まえたよりリアルな切り返しのロープレを実施できた。個別の顧客情報ではなくパターン把握に活用した点が特徴。

音声入力にも対応しているため声を出しながらの練習も可能とのこと。ターゲット読者は「Claude を何に使えばいいかわからない」非エンジニア向けの内容。

Claude Desktop on 3PでBedrockやVertex AIからClaude Desktop動かしたついでにガバナンス合わせて確かめてみた

• URL: https://dev.classmethod.jp/articles/claude-desktop-3p-cloud-bedrock-vertex
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: Claude Desktop の 3P（サードパーティ）モードが 2026年6月アップデートで Chat タブに対応し、Amazon Bedrock と Google Cloud Vertex AI 経由でもフル機能のデスクトップ環境が使えるようになった。あわせて Deployment controls（per-user SSO・MDM ポリシーテンプレート・サーフェス別 policy key）が整備され、Anthropic Enterprise 管理コンソールを使わずとも既存の AWS/GCP の IAM・IdP・MDM・監査ログ基盤でガバナンスを組める構成が公式に固まった。

詳細

Claude Desktop の 3P モードで Chat タブを使うには、3P setup window の「ワークスペースの制限」→「許可されたサーフェス」→「チャット（ベータ）」を GUI で明示的に ON にする必要がある。plist の chatTabEnabled キーだけでは不十分で、MDM 配布時も managed config に chatTabEnabled: true を含める必要がある。

Bedrock 接続では、Named Profile・IAM Identity Center SSO（inferenceBedrockSso* 4キーセット）・Bearer Token・Credential Helper の4経路が選択できる。per-user 監査の観点では Bearer Token は共有キー扱いのため本番非推奨で、IAM IC SSO か Named Profile が推奨される。IAM IC SSO の inferenceBedrockSso* は organization インスタンス（AWS Organizations の管理アカウントで有効化した IAM IC）が前提であり、account インスタンスでは ListPermissionSets が ValidationException になる。

Vertex AI 接続では「接続テスト」ボタンが機能せず（メインプロセスから ADC に直接アクセスできない Electron の制約）、「変更を適用」→ 再起動→ 実動確認の手順が必須。Cloud Audit Logs の RawPredict にメールアドレスが principal として記録される（Claude Desktop 経由は curl 直接より 4〜5 分遅延する場合あり）。

ガバナンス設計の要点として、Developer Mode の「ワークスペースの制限」GUI はユーザー自身が変更できるため組織ガバナンスとしては不十分で、MDM（Intune/Jamf/GPO）で push した managed config は上書き不可となる。3P setup window のポリシーテンプレートは macOS では .mobileconfig、Windows では .reg としてエクスポートできる。

サーフェス別 policy key は chatTabEnabled / coworkTabEnabled / isClaudeCodeForDesktopEnabled の3つ。ツール制御は builtinToolPolicy / disabledBuiltinTools / managedMcpServers / isLocalDevMcpEnabled / isDesktopExtensionEnabled で行える。managed config は「1設定 = 1 AWS アカウント + 1 権限セット」の制約があり、グループ別に異なるポリシーを与えるには MDM 側で別プロファイルを配布する必要がある。

Bedrock の推論通信経路はデフォルトでパブリックエンドポイント（bedrock-runtime.{region}.amazonaws.com）。閉域網要件がある場合は Interface VPC Endpoint（PrivateLink）と Client VPN/Direct Connect または VPC 内プロキシを組み合わせ、inferenceBedrockBaseUrl で接続先を上書きする。IAM IC 認証（oidc.{region}.amazonaws.com 等）は PrivateLink の対象外で別途 egress が必要になる点に注意が必要。

CloudTrail で InvokeModel イベントに assumed-role/cm-seino.example/cm-seino.example 形式の per-user identity が記録されることを実機確認済み。Bedrock model invocation logging を S3 に有効化するとプロンプト・トークン数まで記録できる（CloudTrail データイベントは $0.10/100K events のオプション）。

Enterprise と 3P の使い分け基準: Anthropic 管理コンソールの SCIM/RBAC/Compliance API 一元管理が最優先なら Enterprise。推論を自社クラウドに閉じたい・既存の AWS/GCP 基盤を活用したい・Anthropic への seat 課金を避けたい場合は 3P が適している。

Azure AI Search（Foundry IQ）とMicrosoft FoundryでRAGをつくる

• URL: https://dev.classmethod.jp/articles/create-rag-with-azure-ai-search-and-microsoft-foundry
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: クラスメソッドの浅野大輝氏が、Azure AI Search（Foundry IQ）と Microsoft Foundry を使って個人の文章資産（短歌評論文、約 30,000 文字）を RAG として活用する構成を構築・検証した手順記事。Blob Storage にドキュメントを配置し、Azure AI Search がベクトル化（text-embedding-3-small）してインデックスを生成、Microsoft Foundry 上の gpt-5-mini エージェントが回答を合成する構成で、インターネット非公開のドキュメントを対象に回答取得に成功している。設定項目は多いが、マネージド ID による権限連携やモデルデプロイを含めて一通りの手順が具体的な設定値とともに示されている。

詳細

構成概要として、Azure Blob Storage にドキュメントを格納し、Azure AI Search（Foundry IQ）がテキストをベクトル化してインデックスを生成、Microsoft Foundry 上のエージェントが検索結果をもとに自然文で回答を合成する RAG パイプライン。

リソース設定の主な値は以下の通り。リソースグループ: rg-my-rag、リージョン: (Europe) Sweden Central（モデル利用可能リージョンの制約から選択）、ストレージアカウント: stamyrag（冗長性: LRS）、AI Search サービス名: ais-my-rag（価格レベル: Free）、Microsoft Foundry プロジェクト: msf-my-rag。

権限連携として、AI Search 側でシステム割り当てマネージド ID を有効化し、ストレージアカウント側でそのマネージド ID にストレージ BLOB データ閲覧者ロールを付与する。API キー認証は使わずマネージド ID を使用。

モデルのデプロイとして、Embedding 用に text-embedding-3-small、回答生成用に gpt-5-mini を Microsoft Foundry からデプロイした。

データインポートの手順として、AI Search の「データのインポート」から Azure Blob Storage をソースとして選択し、Foundry の text-embedding-3-small を紐付けてベクトル化処理を設定。インポート完了後にデータソース・インデックス・インデクサー・スキルセットの 4 リソースが生成される。インデクサーのスケジュールは「一度だけ」に設定（定期自動更新も可）。

ナレッジとナレッジベースの関係として、Foundry 上で「ナレッジ」（AI Search インデックスの指定）を作成し、その上に「ナレッジベース」（複数ナレッジソースをまとめてエージェントから利用可能にするリソース）を構築した。ナレッジベースの設定はチャット入力候補モデルに gpt-5-mini、出力モードに「応答の合成」を指定。

動作確認として、「浅野が短歌の連作について話していることをナレッジから探して」というクエリに対し、連作空間論.txt の内容（連作を多次元空間として数学的に定式化するアプローチ、〈連作軸〉〈次元〉〈基底〉などの概念、出典番号付き）を正しく取得・回答できることを確認した。

注意点として、Microsoft Foundry は変化が著しく（2025 年 11 月発表、2026 年 3 月に新ポータル GA）、利用導線が変更される可能性があること、および今回使用した gpt-5-mini の表記が記事中に登場しているが、これは著者の記述によるもの。

NVIDIA VSS 3.2.0 GA を DGX Spark で動かしてみた

• URL: https://dev.classmethod.jp/articles/dgx-spark-vss-3-2-ga-revisit
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: NVIDIA の VSS（Video Search and Summarization）が 2026 年 6 月 16 日に 3.2.0 として GA リリースされた。クラスメソッドの森茂氏が DGX Spark（GB10 搭載、128 GiB Unified Memory）上でフル構成を実機検証した記録。主な変更点は全マイクロサービスのソース公開（Apache-2.0 + MIT）とデプロイ構造の刷新で、base profile では Local LLM（Nemotron-Nano-9B-v2 FP8 on vLLM）がそのまま動作することが確認された。公式ドキュメントでは DGX Spark を「Remote LLM 限定」と位置付けているが、実装レベルでは base profile に限り Local LLM が動く状態になっている。

詳細

VSS 3.2.0 GA（2026-06-16 リリース）の主要変更点は以下の通り。

NEW: 全マイクロサービスとエージェントワークフローの GitHub ソース公開（Apache-2.0 + MIT）、Agent Skills (EA)、NemoClaw + VSS (EA)、RT-CV-3D（Sparse4D v2.2）+ Auto Calibration、音声付き動画理解（Nemotron 3 Nano Omni）。

CHANGED: キャプション生成エンドポイントが /v1/generate_captions_alerts から /v1/generate_captions にリネーム、base profile から Envoy/SDR routing を撤去、デプロイ構造を developer-profiles/ + services/ の include モデルへ刷新。

FIXED: 重複 stream/camera ID に HTTP 409 を返すよう変更（旧は silent overwrite）、Riva ASR NIM の compose 同梱を停止。

デプロイ構造の実態として、dev-profile.sh が nvidia-smi の GPU 名から DGX-SPARK を自動判定し HARDWARE_PROFILE=DGX-SPARK を generated.env に書き込む。HAProxy がポート 7777 で API Gateway 役を担う。

Local LLM の動作確認として、docker inspect でコンテナが nvcr.io/nvidia/vllm:25.12.post1-py3 で起動していることを確認。モデルは nvidia/NVIDIA-Nemotron-Nano-9B-v2-FP8、gpu-memory-utilization 0.40、tensor-parallel-size 1 で起動。tool-call パーサは nemotron_json を指定。

起動時間の実測では、Image pull 約 55 秒、Container 起動カスケード約 13 分（VLM NIM の TRT-LLM コンパイル待ちが支配的）。純粋な起動カスケードは約 9 分、合計 10 分前後が代表値。

API 上の注意事項として、同一 stream_id / camera_id に対し ServiceException（DuplicateStreamId / DuplicateCameraId、HTTP 409）が返る。同じ RTSP URL への複数回呼び出しは UUID v4 で別ジョブとして扱われる。base profile では Envoy + SDR routing を経由せず Stream Processing に直接接続。

ソース公開による自前ビルドの検証として、services/agent/docker/Dockerfile から multi-stage ビルドを実施。security-patches ステージで libssl3 の固定 URL（3.0.19-1~deb12u2）が HTTP 404 になる問題が発生し、apt-get download libssl3 による自動取得に書き換えることで回避した。修正後のビルドは約 8 分で完走し、最終 image サイズは 1.98 GB と公式 image と同一サイズに収まった。

公式の DGX Spark ポジションは「AGX/IGX Thor および DGX Spark は Remote LLM 構成のみサポート、Local 完全デプロイは将来リリース予定」だが、hw-DGX-SPARK.env と vLLM 公式 compose の組み合わせで base profile に限り Local LLM が実動作する状態になっている。alerts / search プロファイルは依然 Remote LLM 必須。

Riva ASR NIM は 3.2 で compose から撤去され、Nemotron 3 Nano Omni VLM のネイティブ audio パスに切り替わった。次回記事で実機検証予定とのこと。

Config 2026で発表されたFigmaの新機能まとめ

• URL: https://dev.classmethod.jp/articles/figma-config-2026-recap
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: Figma の年次カンファレンス Config 2026（2026-06-23〜25）で発表された 8 機能のまとめ。即日利用可能なものは Figma Motion（タイムラインアニメーション）、Generative plugins（自然言語によるプラグイン生成）、Shaders（AI シェーダー）、Figma Weave（複数 AI モデルを組み合わせたノードベースワークフロー）、Figma agent（Skills 機能付き AI エージェント）の 5 つ。Code Layers・FigJam agent・Slides agent は近日公開予定。

詳細

Figma の年次カンファレンス Config 2026（2026-06-23〜25）で発表された 8 機能の詳細まとめ。AI・コード変換・アニメーション領域が中心で、Figma Motion のアニメーション機能が特に注目された。

即日利用可能な機能:

Figma Motion — タイムラインとキーフレーム、プリセットを使ってキャンバス上でアニメーションを直接制作。位置・不透明度・スケール・回転・フェードイン/アウト・イージングを支援。Dev Mode で確認でき、CSS・JSON・React コード・MP4・WebM・Animated SVG・GIF で書き出し可能。

Generative plugins — 作りたいプラグインの内容を説明するだけで独自プラグインを生成。ローカル環境や Figma プラグイン API の知識不要。ファイル内共有から始まり、将来的にチーム・組織・コミュニティへ段階的公開を予定。

Shaders — プロンプト記述または画像参照で質感・エフェクトを生成する AI シェーダー機能。生成後はパラメータ化されてキャンバス上で直接調整可能、コードとして共有・再利用も可。インタラクティブシェーダーは近日提供予定。

Figma Weave — 複数の AI モデルや生成フローをノードベースで組み合わせ、画像生成・スタイル変換などを Figma キャンバス上で構築・反復。テンプレートとして公開・リミックスに対応。

Figma agent — Skills という仕組みでワークフロー・設計規約をエージェントが再利用できる指示としてパッケージ化。Notion・Slack・GitHub との外部連携対応、エージェントとのやり取りがデフォルトでチームに共有表示。

近日公開・早期アクセス受付中の機能:

Code Layers — デザインレイヤーをワンクリックでインタラクティブなコードレイヤーに変換し、同一ファイル内で複数案を並べて探索・コメント反復が可能。コード→デザインレイヤーへの逆変換にも対応。7 月ロールアウト予定でウェイトリスト受付中。

3D transforms — レイヤーに 3D 変形を加える機能。早期アクセス受付中。

FigJam agent / Slides agent — Figma agent の FigJam・Figma Slides 対応。FigJam でアイデア整理・共同作業支援、Slides でスライド構成支援を予定。Coming Soon でウェイトリスト受付中。

Figma Motion・Shader・Generative plugins・Figma Weave・Figma agent は公式 Playground（Config 2026 Playground、Figma agent Playground）でチュートリアル形式で体験できる。

Claudeの指示はどこまで効く？ CLAUDE.md・メモリ・スキルの「効く範囲」を整理してみた

• URL: https://dev.classmethod.jp/articles/kash02_claude_context
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: Claude の各種指示（CLAUDE.md・スキル・rules・Auto memory）がどの範囲で有効になるかを整理した解説記事。Claude Code では CLAUDE.md が作業ディレクトリからルートまで複数階層で加算読み込みされ、起動点に近い＝後に読まれるものが優先されやすいとされる。App（claude.ai）では「アカウント全体・プロジェクト内・その会話だけ」の3単位で有効範囲が決まり、ファイル系のスコープは存在しない。Auto memory はリポジトリ単位で ~/.claude/projects/ 以下に保存されるためプロジェクトをまたいで共有はされない。

詳細

対象環境: App（claude.ai・デスクトップアプリ・モバイル）と Claude Code（VSCode・ターミナル）の2つ。Enterprise・commands（非推奨）・–append-system-prompt などのセッション限定 CLI オプション・各ファイルの読み込み順序の詳細は対象外。

App 側の指示と有効範囲:

• 組み込みシステムプロンプト: Anthropic が自動付与、Claude App 全体に適用（docs.claude.com/en/release-notes/system-prompts で公開）
• パーソナライズ（設定 > 一般の「Claudeへの指示」）: プロジェクト外の通常チャットのみ
• メモリー（設定 > 機能から有効化）: プロジェクト外の通常チャットのみ
• プロジェクト指示: そのプロジェクト内のチャットのみ
• プロジェクトのメモリー: そのプロジェクト内のチャットのみ
• スキル（Customize > Skills）: Claude App 全体

設定は Anthropic サーバーに保存されるが、デスクトップアプリの Cowork プロジェクトはローカル PC フォルダに保存する場合もある。

Claude Code 側の指示:

• CLAUDE.md: ユーザー指示（~/.claude/ 以下）は常時参照、プロジェクト指示は作業ディレクトリからルートに向かって全階層を加算読み込みする。複数ファイルは AND で積まれ上書きではない。矛盾時は具体的で後に読まれるもの（起動点に近いもの）が優先されやすいとされるが、CLAUDE.md については保証された挙動ではない
• skills: enterprise > personal > project の優先順位で同名スキルが重複する場合は上位が優先。それ以外は加算
• rules: skills とほぼ同じ参照範囲。矛盾時は作業ファイルに近いものが優先（skills の優先順位とは異なる点に注意）
• Auto memory: リポジトリ単位で ~/.claude/projects//memory/ に保存。同一リポジトリ内であればサブフォルダや複数 worktree でも同じメモリを共有する。App 版メモリーと違ってリポジトリをまたいで反映されない

現在の読み込み状態確認には /memory コマンドが利用できる。

【チョークトークレポート】フィジカルAIはクラウド？エッジ？決め手は「許容できる◯◯」─ソラコム松下さんが解説

• URL: https://dev.classmethod.jp/articles/physical-ai-latency-edge-or-cloud
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: AWS Summit Tokyo 2026 のチョークトークで、ソラコム松下享平氏がフィジカル AI のクラウド vs エッジ選択について解説。クラウド経由のレイテンシーは実測約 100ms で、ニールセン・ノーマン・グループの研究が示す人間の違和感閾値（100ms）と合致するため許容範囲内。エッジはネットワーク遅延がない一方でモデルサイズやハードウェア制約から推論時間が長くなる傾向があり、許容できるレイテンシーが選択の決め手になるという主張。

詳細

AWS Summit Tokyo 2026（2026-06-25 11:30〜12:00）にて、ソラコム松下享平氏によるチョークトーク「クラウド?エッジ？どっち？〜ロボアームと AWS サービスで考えるフィジカル AI アーキテクチャ」のセッションレポート。チョークトークはスピーカーと参加者が双方向に議論する対話型形式。

ロボットアームを USB 直結と AWS（クラウド）経由の両方で操作するデモを実施。クラウド経由のレイテンシーを参加者に予想させた上で実測すると約 100ms だった。ニールセン・ノーマン・グループの研究では「人間は 100ms 以上の遅延で違和感を感じ始める」とされており、クラウド通信の 100ms はその閾値に収まることを示した。

比較として、自販機ボタンが 1 秒後に反応すると「故障かも」と感じるという直感的な例を用いて閾値を説明。クラウド AI の 100ms 遅延は許容範囲内だが、エッジ AI はネットワーク遅延ゼロの代わりにモデルサイズやハードウェア制約から推論時間が長くなる傾向があり、加えてモデルのデプロイ・運用コストも考慮が必要。

アーキテクチャ選択の指針は「許容できる遅延」であり、シビアな遅延要件がない場合は AWS Bedrock・SageMaker を活用したクラウド AI が有力。エッジへのモデルデプロイが必要な場合は AWS IoT Greengrass を使う手段もあり、松下氏自身が builders.flash に解説記事を執筆している。本セッションは re:Invent 2025 セッション「DEV316: Designing local Generative AI inference with AWS IoT Greengrass」をアレンジしたもの。

カスタム権限でカスタムMCPツールの実行を特定ユーザーだけに制限してみた

• URL: https://dev.classmethod.jp/articles/restrict-custom-mcp-tool-by-custom-permission
• 日付: 2026-06-26
• Tier: Tier 2
• 要旨: Salesforce のカスタム MCP サーバーツール（Apex Invocable メソッド）の実行権限を、Salesforce のカスタム権限（Custom Permission）で制御する手法を検証した記事。FeatureManagement.checkPermission() を Invocable メソッドの冒頭で呼び出し、権限がない場合は例外を throw して MCP クライアント側にエラーを返すことで、プロファイルまたは権限セット単位の実行制限を実現した。

詳細

対象環境: Salesforce 上にカスタム MCP サーバーを構築し、Apex Invocable メソッドをツールとして公開している構成。前回記事で実装した商談メモ記録ツール（SfOpportunityNotes）に対して、特定ユーザーだけ実行を許可する制御を追加した。

実装手順:

1. Salesforce でカスタム権限を作成（表示ラベル: 商談メモを活動として記録、名前: Log_Opportunity_Meeting_Note）
2. Apex クラスに定数 REQUIRED_PERMISSION = ‘Log_Opportunity_Meeting_Note’ と LogOpportunityMeetingNoteException を追加
3. Invocable メソッドの冒頭で FeatureManagement.checkPermission(REQUIRED_PERMISSION) を呼び出し、false の場合は例外を throw
4. 例外が throw されると MCP クライアント（Claude）側にエラーが返り、Salesforce への Task レコード作成は一切行われない

動作確認: カスタム権限なしの状態でツール実行すると期待通り権限エラーが発生。プロファイルにカスタム権限を付与して再実行すると成功し、Salesforce に Activity（Task）が登録されることを確認した。

設計上の利点:

• カスタム権限はプロファイルにも権限セットにも割り当て可能で、ユーザーグループ単位の柔軟な制御ができる
• MCP レイヤーではなく Apex レイヤーで権限チェックするため、MCP サーバー側の改修なしに Salesforce の既存権限管理の仕組みをそのまま活用できる
• 権限がない場合はデータが一切操作されない安全な失敗（fail-safe）になる

約2,000人が使うClaude Codeと向き合う。 | CyberAgent Developers Blog

• URL: https://developers.cyberagent.co.jp/blog/archives/64334
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: サイバーエージェントが社内約2,000人のClaude Code利用者を擁する大規模組織として、Claude Code開発者のBoris Cherny氏とQ&Aセッションを実施し、エンタープライズでのAIエージェント運用に関する知見を得た記録だ。セッションでは2028年までの開発プロセス完全自動化の現実性、ガバナンス・コスト管理・教育・ナレッジ共有を含む組織設計、SDLCのどの工程から自動化が進むかなど20以上のテーマが議論された。Boris氏からは、自動化の深さは使い込んだ期間に左右される・コンテキストは最小限にしてエージェント自身が検証できる環境を作る・コストではなくROIで考えるという3つの基本方針が示された。また、手作業をスキル化・繰り返し作業をループやルーティンへ昇格させる考え方や、エンジニアの役割が実装者から目的・制約・検証方法を設計する者へ変化するという展望も語られた。サイバーエージェントは今後、利用状況・コスト・権限・セキュリティの可視化強化と、チームで生まれた良い使い方のスキル化・組織共有を次の課題として進める。

詳細

セッションの背景

• サイバーエージェントは社内約2,000人がClaude Codeを利用し、個人活用から組織全体活用へのフェーズ移行中
• 2026年6月12日にClaude Code作者Boris Cherny氏（Anthropic Head of Claude Code）との直接Q&Aを実施
• 事前に数十件の質問を社内で収集し、20以上のテーマについて議論

議論されたテーマ一覧

• Claude Codeの今後の進化と他AIエージェントとの差別化
• Anthropic社内のAI駆動開発の実態とSDLC全体の自動化
• 2028年完全自動化の現実性と人が残るべき領域
• PRレビュー・セキュリティレビュー・Ops領域の活用
• 大規模組織でのエージェント可視化とガバナンス
• 約2,000人規模の権限管理・設定管理・コスト管理
• CLAUDE.md・スキル・ループ・ルーティンの設計
• AI時代のエンジニア評価・人材像・チーム文化

Boris氏から得られた主な知見（5点）

• 自動化の深さは使い込んだ期間に左右される。ツールを配布するだけでなく継続的に改善し、ノウハウを組織資産に変える仕組みが必要
• ハーネス・コンテキストは最小限にし、テスト・ビルド・ログ等エージェントが自分で検証できるフィードバックループを整備する（Claude Code Best Practicesとも整合）
• コスト削減ではなくROI（投資対効果）で評価し、ボトルネック解消・効果の出るチームを可視化して投資判断につなげる
• 日々の作業を棚卸しし、手作業→スキル、繰り返し→ループ・ルーティンへと昇格させる
• エンジニアの役割は「コードを書く」から「目的・制約・検証方法・運用ルールを設計する」へ広がる

サイバーエージェントとしての今後の課題

• 利用状況・コスト・権限・設定・セキュリティの可視化基盤を強化
• 各チームで生まれた良い使い方をスキル・ルーティンとして横展開
• 非エンジニア向けClaude Code研修・AI活用度の可視化を組織全体で推進

Claude Code / Codex の全社展開とAI観測基盤の設計 | ドクセル

• URL: https://docswell.com/s/rakutek/59NR49-2026-06-04-194729
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: クラシル株式会社のAIエンジニアが、Claude CodeとCodex CLIを全社展開した後に直面した「誰がどう使っているか見えない」問題を、OpenTelemetryとGrafanaを組み合わせた観測基盤で解決した設計を公開したスライドだ。Claude CodeはTeam/Enterpriseプランで2026年2月からOTel対応が追加されており、OTEL_*環境変数を設定するだけでメトリクス・ログをエクスポートできる。クラシルは多様なプラン・個人契約が混在する環境に対し、managed-settings.jsonをJamf（MDM）で全macOSに一括配布することで管理者操作ゼロ・全社員カバーを達成した。Codex CLIも同様の設計思想でmanaged_config.tomlをMDM配布し、同一のGrafana Cloudダッシュボードに統合している。今後はGitHub API・Notion APIをGrafana Infinity datasourceで読み込み、AIへの入力ログと開発アウトプットの両面を同一ダッシュボードで対比させるアーキテクチャを構築中で、計測した数字はすでに同社の決算資料にも掲載された。

詳細

背景と課題

• クラシルはChatGPT→Cursor→GitHub Copilot→Claude Max→Claude Team（2026/2）と段階的に全社導入
• 全社導入完了後も利用実態が不明で、数百人規模では個別ヒアリングは非現実的
• Claude Team/Enterprise・個人契約Claude Max・Codex CLIが混在し管理者設定だけでは全員をカバーできない

観測基盤の技術選定（段階①: 観測する）

• Claude Code（Team/Enterprise）は2026年2月以降OTelネイティブ対応、OTEL_*環境変数でOTLPエクスポート
• Codex CLIもOTel対応、config.tomlの[otel]セクションで設定
• 収集先にGrafana Cloud（OTLP互換）を採用

MDM配布による全社カバーの解決策

• managed-settings.jsonをJamfで全macOSに配布（ユーザー上書き不可の組織レベル設定）
• 設定ファイルパス: /Library/Application Support/ClaudeCode/managed-settings.json
• CLAUDE_CODE_ENABLE_TELEMETRY・OTEL_METRICS_EXPORTER・OTEL_LOGS_EXPORTER等を強制ON

Claude CodeとCodex CLIの取得フィールド差異

• Claude Codeのみ: cost_usd（実コスト）・スキル名skill_name・キャッシュトークン内訳・推論エフォート
• Codex CLIのみ: ツール実行全文（コマンド・stdout・承認可否）・実行環境情報・分散トレース
• Codex CLIにはcost_usdがないため、モデル×トークン数から概算換算ロジックで推定値を算出

構想中のアーキテクチャ（段階③: 成果と繋ぐ）

• GitHub API・Notion APIをGrafana Infinity datasourceで直接読み込み（専用ETL不要）
• HRMOSとGitHubユーザーを紐付けて社員・部署単位での集計を実現
• 入力側（トークン・コスト）と出力側（PR数・Notionドキュメント）を同一ダッシュボードで対比

成果

• 計測した利用データが決算説明資料に掲載される水準の信頼性を確保

生産性向上を「個人レベル」から「組織レベル」へ　15人のデザイナーで「Claude Code × GitHub」で組織運営をした結果｜Goodpatch Blog グッドパッチブログ

• URL: https://goodpatch.com/blog/2026-06-github
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: グッドパッチのサービスデザイナーチーム15人が、Claude CodeとGitHubを軸に組織の生産性を個人レベルから組織レベルへ引き上げる取り組みを2ヶ月間実践し、その経緯と成果を報告している。個人がAIで高速にアウトプットを出しても、コンテキストの共有・接続ができなければ組織の生産性は上がらないという問題意識から、議事録・成果物・進捗をGitHubに一元管理する体制に移行した。GitHub初心者のデザイナーが多いため、GitHub Desktopを入口にし、フォルダ構成とフロントマター付きMarkdownでシンプルな運用ルールを整備した。GASとGitHub Actionsで会議録を自動集約し、Claude Codeがその蓄積コンテキストを基に月次報告の叩き台を生成できるようになった。2ヶ月を経て情報をZIPファイルで送り合うSlackベースの運用が消え、GitHubを中心にコンテキストが組織として積み上がるエコシステムが根付きつつある。

詳細

課題認識

• 個人がClaude Codeで高速にアウトプットを出しても、ZIPやSlack添付でのファイル共有ではコンテキストが引き継がれず、受け取り側の品質・スピードが伸び悩む
• 生産性の高い個人が多くても生産性の高い組織にはならないという前提から出発

参加者と体制

• サービスデザイナーチーム約15名、5チーム（AI研究目的の組織貢献活動）
• 多くはGitHub未経験のデザイナー

GitHub運用の設計方針

• ブランチを切らずmainで直接作業、その日の日付フォルダ内のみ個人が自由に編集するルールでコンフリクトを回避
• フォルダ構成: team-*/members/（個人の自由スペース）、team-*/meeting-notes/、team-*/docs/、team-*/sprints/、shared/（横断共有）
• 共有Markdownにフロントマターを必須化（id/title/depends_on/affects/version/last_updated/status）して、AIが文書の鮮度・所属を把握できる状態を維持
• claude.ignoreでmembers/以下を AIのコンテキスト読み込み対象から除外

議事録の自動集約

• GAS（Google Apps Script）がGoogle Meet自動議事録をGitHubリポジトリに連携
• GitHub Actionsが会議名のキーワードを読み取り各チームのフォルダへ振り分け、毎日定期実行

モーニングブリーフィング

• 未完了ToDo・前日5チームの議事録ハイライト・直近3日のGitコミット個人別集計を毎朝Slackへ自動配信
• morning-briefingスキルとscheduleの組み合わせで実現

2ヶ月後の変化

• Slackでのファイル添付送付がゼロに
• 月次報告の叩き台をAIが過去のコンテキストを基に自動生成できるようになった
• GitHub活用はエンジニア専有ではなくホワイトカラー全員必須のツールだという認識に変化

Claude Codeのフックで「自分専用セカンドブレイン」を作る ─ 10本超のフック構成と実装例

• URL: https://qiita.com/tateishi-t/items/03529caccd796a8a8dcf
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude Codeのhooks機能を10本超・3層構造（global/project/project-local）・5カテゴリで構成した個人運用事例の詳細レポート。Stopフックでセッションを自動的にObsidian Vaultに保存する仕組み、PreToolUse(Read)でoffset/limit未指定時にsystemMessageで自己リマインドするフック、3層構造による設定分離の設計が主に紹介されている。自動push起因の.env.bakキー漏洩・launchdサンドボックスによるファイル生成失敗・フック過多による起動重化・ゾンビフックの発見という4件のアクシデント事例と対応も共有されている。

詳細

• フックイベント: SessionStart・Stop・PreToolUse・PostToolUse・SubagentStop・Notification。matcherでツール名フィルタ可能
• 3層構造:
  • Global（~/.claude/settings.json）: 全プロジェクト共通フック・デニーリスト・Wiki同期
  • Project（/.claude/settings.json）: チーム共有のプロジェクト固有フック（typecheck・機密保護）
  • Project Local（/.claude/settings.local.json）: gitignore対象の個人許可リスト・MCP有効化
• 紹介フック3本:
  1. session-end-to-vault.sh（Stopフック）: セッション終了時に会話をObsidian Vaultへ自動保存
  2. PreToolUse(Read)リマインダー: jqで.tool_input.offsetまたは.limitがnullのときsystemMessage返却 → 大ファイル全文Readを抑制
  3. hot-md-updater.sh（Stopフック）: Claude Haikuを呼んで当日作業サマリを~/.claude/hot.mdに生成し次セッションで自動読み込み
• アクシデント事例:
  1. 自動pushフックで.env.bakのAPIキーがリポジトリに混入 → gitleaksで数週間後に発見。git filter-repoで履歴削除・キーローテーション
  2. launchdサンドボックスでスクリプト成功ログが出るのにファイルが生成されない → WorkingDirectory明示と実体ファイル存在チェック追加で解決
  3. SessionStartフック過多で起動が重化 → async: true活用と不要フックの棚卸し（半年に1回）
  4. settings.jsonに登録漏れのゾンビフックが3本 → スクリプトとhooksセクションの突き合わせと出力ログ確認を習慣化

【自作】ノンエンジニアがCursorのVibe Codingで作ったChrome拡張機能「Tab to MD」開発記録

• URL: https://qiita.com/tateishi-t/items/1b9319fe3ccd2428363a
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: ノンエンジニアがCursorのVibe Codingを使い、開いているタブを一括でMarkdownファイルとして保存するChrome拡張「Tab to MD」を開発した記録。Manifest V3・Service Worker・chrome.scripting.executeScript等の技術的制約にぶつかりながら、AIとの対話でトライアンドエラーを繰り返した経緯が記録されている。ダウンロードフォルダ外の絶対パス指定ができないChrome APIの制約を受けて、ダミーファイルダウンロードでフォルダパスを取得するという回避策を実装している点が興味深い。

詳細

• 機能: 現在ウィンドウの全タブを1ページ1ファイルでMarkdown変換・保存、保存先フォルダのカスタマイズ
• 技術スタック: Manifest V3、Service Worker、Vanilla JavaScript、Chrome APIs（tabs・storage・downloads・scripting）
• Manifest V3の注意点: chrome.tabs.executeScriptが廃止されchrome.scripting.executeScriptを使用。background pageからService Workerへ移行
• メッセージパッシングでreturn trueが必須（非同期処理でチャネルを開き続けるため。falseや未返却だとsendResponseが呼ばれる前にチャネルが閉じる）
• chrome://・chrome-extension://・about:などの特殊ページはセキュリティ上アクセス不可。事前URLチェックでタブ情報のみを使用してMarkdown生成
• ファイル名のサニタイズ: 特殊文字をアンダースコア置換・スペース置換・100文字制限
• ダウンロードパスの制約: chrome.downloads APIはダウンロードフォルダ外の絶対パスを受け付けない。絶対パス設定時はsaveAs: trueでダイアログ表示
• フォルダ選択の回避策: フォルダ選択APIが存在しないため、ダミーファイルをダウンロードさせてその保存先パスを取得する方法を採用

Intel Mac 2018（i7/32GB）で動く“日本語OKなローカルLLM”を比較・選定する（準備編）

• URL: https://qiita.com/tateishi-t/items/85af44e9d6fe11a047b4
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Intel Mac（2018、i7/32GB、内蔵GPU非力）でCPU推論できる日本語ローカルLLMを比較・選定した準備編。7B〜13B級のq4量子化モデルを対象に、日本語の自然さ・構造化力・体感速度・メモリフットプリント・ハルシネーション安定性の5軸で8モデルを比較している。ビジネス文書（議事録整形・メール下書き）への活用を主な用途として想定し、Llama 3.1 8B Instructを基準器として第1優先に、Qwen2.5 7Bを第2優先として選定している。次回記事でOllamaを使った実際のインストール・動作確認を扱う構成。

詳細

• 検証環境: MacBook Pro 15-inch 2018 / Intel Core i7 6コア / 32GB RAM / 内蔵Intel UHD 630 / macOS Sequoia 15.6
• 評価基準5軸: 日本語の自然さ（敬語・ビジネス文）、構造化力（要点抽出・章立て）、体感速度、メモリフットプリント（q4常用可否）、ハルシネーション安定性
• 主要候補モデル比較:
  • Llama 3.1 8B Instruct（Meta）: q4メモリ5-6GB、日本語・速度・構造化のバランス最良 → 第1優先
  • Qwen2.5 7B Instruct（Alibaba）: q4メモリ4-5GB、多言語強め → 第2優先
  • Gemma 2 9B IT（Google DeepMind）: q4メモリ6-7GB、章立て・長文構造化の安定感 → 第3優先
  • Mistral 7B Instruct v0.3: q4メモリ4-5GB、速度特化のバッチ処理向き
  • ELYZA 13B: q4メモリ9-11GB、日本語ニュアンス精度特化（速度△）
  • Phi-3.5-mini（3.8B）: q4メモリ2-3GB、超軽量だが長文・高度推論は苦手
• 推奨運用: Llama 3.1 8Bを基準器、速度重視日はMistral 7B、敬語精度を上げたい日はELYZA 13Bに差し替え
• 次回: brew install ollamaでインストール後、3モデルをpullして動作確認

Intel Mac 2018（i7/32GB）で動く“日本語OKなローカルLLM”を比較・選定する（実施編）

• URL: https://qiita.com/tateishi-t/items/f42b3e7eb2741cac3a98
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Intel Mac（2018、i7/32GB）上でLlamaIndex・Ollama・ChromaDBを統合したローカルRAGシステムを構築した実践記録。LlamaIndexエコシステムの依存関係衝突という最初の壁を、各コンポーネントのバージョンを厳密に固定することで突破している。用途別（note・Qiita・ビジネス）にドキュメントを整理し、フォルダを分けてベクトルDBに格納することで回答ノイズを削減する設計を採用した。実際の使用感として文章生成に時間がかかり実務でのリアルタイム利用は難しいと正直に評価されている。

詳細

• 要件: 完全ローカル稼働・用途別カスタマイズ（note/Qiita/ビジネス）・Intel MacでのCPU推論
• 依存関係の解決が最大の課題。安定バージョンセット:
  • llama-index-core: 0.11.0
  • llama-index-llms-ollama: <0.5（0.4.x系）
  • llama-index-embeddings-huggingface: <0.4（0.3.x系）
  • llama-index-vector-stores-chroma: 0.3.0（core<0.12.0かつchromadb>=0.5.17の制約で全体の鍵）
  • chromadb: >=0.5.17
  • sentence-transformers: 2.7.0
  • pypdf: 4.3.1
• RAGパイプライン: SimpleDirectoryReader → HuggingFaceEmbedding → ChromaVectorStore → VectorStoreIndex → Ollama（llama3.1-8b-ja）
• 用途別データ構造: corpus/note/・corpus/qiita/・corpus/business/ でフォルダを分離。メタデータフィルター（filters={“domain”: “business”}）で検索対象を限定
• 拡張計画: domainメタデータでプロンプトを動的分岐し、回答のトーンやフォーマットをユーザーが制御できる設計
• 実用上の課題: CPU推論のため文章生成に時間がかかり、リアルタイムの実務利用は困難

セールスのオンボーディング期間を3分の1に短縮した内製の「AIロープレ」

• URL: https://tech.layerx.co.jp/entry/2026/06/25/162902
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: LayerXのバクラク事業部が、セールス向けオンボーディングの課題を解決するためにAIロープレシステムを内製し、オンボーディング期間を約3分の1に短縮した。13プロダクトを扱う商談を想定し、画面共有デモを含む実戦再現・商談シナリオの自動生成・学習コンテンツへの動線設計の3点にこだわって自社開発を選択した。導入後は新メンバーが週に最大30回自発的にロープレを実施し、ランチング1回目まで約3週間、対人ロープレ回数も10回以上から約3回へと激減している。音声対話にはAzureのSTT/TTSとLLMを組み合わせたリアルタイム会話エンジンを採用し、商談終了後の評価も別途LLMが担う二段階構成となっている。今後は量の確保から質の向上へと舵を切り、熟練セールスの暗黙知をAIフィードバックに落とし込む取り組みを進める予定だ。

詳細

背景と課題

• バクラクは13プロダクトを展開するコンパウンド戦略を採り、新メンバーがキャッチアップすべき知識量が膨大
• 従来の対人ロープレ（ランチングチェック）は月10回以上の既存社員負担・先輩待ちによる日程遅延・新メンバーの心理的ハードルという3つの課題があった

内製を選んだ3つの理由

• 画面共有でプロダクトデモを見せながら話す実戦プロセスを再現するため
• 業界/会社規模/ペルソナの組み合わせが無限になるシナリオを自動生成するため（既製SaaSでは手動作成コストが大きい）
• 既存の内製セールスイネーブルメント基盤「SalesPortal」に統合し認証・UIを共通化するため。ロープレ後フィードバックと学習コンテンツが同一画面で完結する設計

技術スタック

• フロント: Next.js
• 音声認識/合成: Azure STT/TTS（モデルは継続的に見直し中）
• 会話生成: LLM（リアルタイム）
• 評価: 別途LLM（商談履歴を商談終了後に送信して採点）

定量成果（Before/After比較）

• ランチング1回目到達: 約1〜2ヶ月 → 約3週間
• ランチング2回目到達: 約3ヶ月 → 約1ヶ月
• 対人ロープレ回数: 10回以上 → 約3回
• 週の最大ロープレ実施回数: 30回近く（AIなら気兼ねなく繰り返せる）

今後の課題

• 現状のフィードバックは基本的な内容にとどまる
• デモ操作の流暢さ・適切な間の取り方・潜在課題の引き出しなど高度な評価軸への対応が次の開発テーマ

再起動を跨いで自律完走するセキュアブート(CVE-2023-24932)自動更新スクリプトの実装

• URL: https://zenn.dev/8chikuwa3/articles/271b18d38820b2
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: BlackLotusブートキット対策としてMicrosoftが段階的に強制しているセキュアブート証明書更新（CVE-2023-24932）を、WSUS運用かつ完全オフラインの閉域網環境で自動化したPowerShellスクリプトの実装記録。手動では「DB/KEK更新→再起動→ブートマネージャー更新→再起動→DBx失効→SVN更新」という複数回の再起動が必要となるが、スクリプトはUEFI変数とイベントログ1042番をスキャンして現在フェーズを判定し、再起動後も自動でタスクスケジューラから再開して処理を継続させる。最終的に監査ログをファイルサーバへ出力し、スケジュールタスクとスクリプト自身を自己消去するクリーンアップ機能も備える。中途半端な状態（DBxのみ更新済み・SVN未了）への対応リカバリモードも実装されている。

詳細

• 対象環境: Windows 11 25H2、WSUS運用・完全オフライン（行政機関・厳格エンタープライズ想定）
• 前提パッチ: 2026年2月の累積更新プログラム適用済み（2025年7月8日リリースの月次パッチを包含）
• セキュアブートの4鍵: PK（PCメーカー）、KEK（今回: Microsoft Corporation KEK 2K CA 2023 追加）、DB（今回: Windows UEFI CA 2023 追加）、DBX（今回: Microsoft Windows Production PCA 2011 失効）
• 手動処理ステップと対応レジストリ値:
  • 0x5944: DB/KEK更新準備 → 再起動
  • 0x4000待機: パッチ受け入れ準備
  • 0x280: DBx + SVN を一括適用（旧: 0x80 → 0x200 の2段階）
• スクリプトの主要機能:
  • Register-ResumeTask: スタートアップトリガー＋10分遅延でタスク登録（AC/バッテリー両対応）
  • Invoke-Cleanup: タスク・レジストリ・スクリプト自己消去
  • Wait-ForRegistryValue: レジストリ値ポーリング（30秒間隔・最大10分）
  • Write-AuditLogAndExit: 最終監査ログ（CSV）をファイルサーバへ出力
• 状態管理: HKLM:\SOFTWARE\ITAdmin\SecureBootUpdate\UpdatePhase に現在フェーズを保存して再起動跨ぎを実現
• イベントID確認ポイント: TPM-WMI ソース（1036, 1043, 1799, 1808, 1037, 1042）
• リカバリモード: DBxのみ更新済み・SVN未了の端末を自動検出して 0x200 を単発実行

Active Directory:CSV読み込んでコンピュータを追加

• URL: https://zenn.dev/8chikuwa3/articles/2950041b380913
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: CSVファイルからActive Directoryにコンピュータアカウントを一括追加するPowerShellスクリプトを紹介している。CSV上のOU名から DistinguishedName を動的に解決し、同名OUが複数ある場合はエラーで停止するフェイルセーフも実装している。既存アカウントはスキップして新規作成のみ行い、作成後に指定グループへの追加まで一連の処理として実行する。

詳細

• CSV形式: PCAddName（PC名）、Description（説明）、TargetOU（OU名のみ記述、DNは不要）の3列
• スクリプトの主な処理:
  1. Get-ADComputer で既存アカウントを確認し、存在する場合はスキップ（ADIdentityNotFoundException のみ新規作成ルートへ）
  2. Get-ADOrganizationalUnit -Filter “Name -eq ‘$TargetOU_Name’” でOU名からDNを動的解決
  3. 同名OUが0件または複数件の場合は例外をスローして処理を中断（フェイルセーフ）
  4. New-ADComputer で Description・Path（解決したDN）を指定して作成し、Add-ADGroupMember で指定グループに追加
• OU名だけCSVに書けばよいシンプルな設計で、DN文字列を手書きする手間とミスを省ける

part1:「机の上が端末だらけ」はもう限界。田舎役所の“情シス”が直面する、三層分離の構造的な限界

• URL: https://zenn.dev/8chikuwa3/articles/33cb40aa3ac5ad
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 田舎小規模自治体の一般事務職員が情シスとして直面する、三層分離ネットワークモデルの構造的限界を現場視点で整理した記事。テレワーク対応のための継ぎ接ぎ対応と二重投資、「閉域網なら安全」神話の崩壊（パッチ適用の遅延常態化・内部侵入後の無防備さ）、そして人も金も足りない一人情シスの運用限界という3つの問題を率直に語っている。解決策として国が進めるゼロトラスト検証事業を次回以降で掘り下げると予告している。

詳細

• 三層分離の3大問題（現場から):

  1. 働き方改革への阻害: テレワークに閉域網回線・VDI・常時電源入れっぱなしPC等の継ぎ接ぎ対応が発生し二重投資が拡大。チャットツールや生成AIも「インターネット端末でしか使えない」と答えざるを得ない
  2. 「閉域網神話」の崩壊: WSUSやウイルス対策サーバーの運用限界でパッチ適用が遅延。USBメモリ・保守業者端末経由で一度内部侵入を許すと内部ネットワークはフラット。VPN/FWの脆弱性を狙った攻撃が主流化している中で境界前提設計の限界が露呈
  3. 一人情シスの運用負荷: 3つのNWそれぞれのFW・プロキシ・ウイルス対策を兼務担当者が管理。24時間監視は物理的に不可能。NW構成がベンダー依存でブラックボックス化し柔軟な変更が困難

• 現在の三層分離は「利便性・セキュリティ・運用体制」の3軸すべてで構造的限界に達しているという総括

• 著者プロフィール: とある田舎小規模自治体の一般事務職員が情シス担当として実務経験をもとに執筆

Active Directory：krbtgt パスワードの安全なリセット手法

• URL: https://zenn.dev/8chikuwa3/articles/3f4c1d680ca8be
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Active Directoryの krbtgt アカウントパスワードを安全にリセットする手順を、PingCastleのルールID「A-Krbtgt」への対応として解説している。krbtgtハッシュ漏洩がゴールデンチケット攻撃の温床になる理由を示した上で、Microsoft公式の対話型PowerShellスクリプトを用いた7ステップの手順を紹介している。特に「時間差で2回リセット」するという鉄則と、本番実施前のダミーアカウントを使った予行演習の重要性を強調している。

詳細

• krbtgt の危険性: ADのKerberos認証チケット（TGT）の暗号化キーを生成するアカウント。ハッシュが漏洩するとゴールデンチケット（偽造TGT）を半永久的に発行できるバックドアになる
• 手動での変更は禁止: ADユーザーとコンピューターから直接変更するとDC間の複製遅延により認証障害が発生するリスクがあるため、PowerShellスクリプトを使用する
• 使用スクリプト: Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1（GitHubから取得）
• 9つのモードのうち主要なもの:
  • Mode 2（カナリアテスト）: 全DCへの同期時間を測定する必須ステップ
  • Mode 4（テストリセット）: ダミーアカウントで本番同等の予行演習
  • Mode 6（本番リセット）: 実際のリセット実行
• 時間差2回リセットの理由: ADはKerberos認証の互換性確保のため「現在」と「1世代前（N-1）」の2世代のパスワード履歴を有効なものとして扱う。古いハッシュを完全に無効化するには10時間以上の待機を挟んで2回リセットする必要がある
• 7ステップ手順: Mode 8でダミー作成 → Mode 2で同期確認 → Mode 4で予行演習 → Mode 5で本番直前確認 → Mode 6（1回目） → 10時間以上待機 → Mode 6（2回目）

part4:スモールで始めるリスクアセスメントと移行ステップ

• URL: https://zenn.dev/8chikuwa3/articles/63f957e0f3da87
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 自治体の一人情シス向けに、三層分離からゼロトラストへの移行を現実的な3段階ロードマップとして整理した最終回記事。「3つの層 × 3つの観点（侵入・横移動・持ち出し）」による色分けだけで始められるシンプルなリスクアセスメント手法を提案している。Phase 0（資産棚卸し・ID統合・MFA導入）、Phase 1（EDR+MDR）、Phase 2（ZTNA）、Phase 3（基幹系のVDI活用）と段階的な移行ステップを示し、「完璧なゼロトラスト」より「持続可能な仕組み」を目標に置くことを強調している。

詳細

• リスクアセスメントの簡易手法: 「3層 × 3観点（侵入/横移動/持ち出し）」で現状を色分けするだけでよい。MFAなし・フラットNW・USB制限なしは赤信号。「閉域網だから低リスク」は誤認
• Phase 0（準備）:
  • ADのアカウント棚卸し（退職者ID洗い出し）。PowerShellスクリプト例: Search-ADAccount -AccountInactive で180日未ログインアカウントを抽出
  • ID統合・SSO: まずSaaSからM365等で小さく始め、残存システムは次期更改時の調達仕様書に「SAML/OIDC必須」と明記して段階統合
  • MFA強制: 反発には「総務省ガイドライン・自治体情報セキュリティポリシー」を盾として使う
• Phase 1（エンドポイント）: EDR単体導入は禁止。MDR（外部委託）またはSOC相乗りとセットで導入。MDM連携でパッチ未適用端末のアクセスをシステム的に遮断
• Phase 2（ネットワーク）: ZTNAで1台の端末からLGWAN業務もインターネット業務もシームレスに利用できる環境を実現
• Phase 3（基幹系）: 住民情報・税務情報を扱う基幹系はVDIや画面転送が現実解。IEモード依存など制約があるため最後に取り組む

GPOを使った無線LANプロファイルの配布

• URL: https://zenn.dev/8chikuwa3/articles/64ab9b612164ca
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 自治体のLGWAN接続系など、接続先SSIDを制限する必要がある環境向けに、グループポリシー（GPO）を使って無線LANプロファイルの配布と接続先制限を行う手順をまとめた記事。「ワイヤレスネットワーク（IEEE 802.1）ポリシー」でEAP-TLS認証プロファイルを作成し、許可SSIDのみを表示させる設定を配布することで、端末側での誤接続を防ぐ構成を実現している。ADCSとNPSを使ったEAP-TLS無線LAN構築記事と組み合わせることを前提とした補足記事。

詳細

• 対象: 自治体LGWAN接続系環境での無線LAN接続制限（地方公共団体情報セキュリティポリシーガイドライン準拠）
• GPOパス: コンピューターの構成→ポリシー→Windowsの設定→セキュリティの設定→ワイヤレスネットワーク（IEEE 802.1）ポリシー
• プロファイル設定:
  • 認証: WPA2/WPA3エンタープライズ（環境に応じて選択）
  • 認証方法: EAP-TLS（スマートカード）
  • ルート証明機関を明示指定
• 接続制限設定: 「インフラストラクチャネットワークに接続しない」にチェックで許可SSIDのみ表示
• アドホックネットワークも同時に制限可能
• OUに対してGPOを割り当てることで配布完了
• 確認コマンド: netsh wlan show filter（SSIDフィルタの適用状況を確認）

Active Directory:OU階層とGPO適用状況をツリー状テキストに出力

• URL: https://zenn.dev/8chikuwa3/articles/65f609d528fa0e
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Active DirectoryのOU階層とGPO適用状況を、リンク順序・強制・無効の状態も含めてツリー状のテキストファイルに一括出力するPowerShellスクリプトを紹介している。標準コマンドレットでは取得できないドメインルートのGPOも網羅し、gPLink属性を直接パースすることでリンク順序（Order）を抽出している。長年の運用で蓄積したゾンビGPOや継承ブロックの把握・引き継ぎ資料の作成に役立てることができる。

詳細

• 課題背景: GUIや標準コマンドレットでは「どのOUにどのGPOが何番目の優先順位でリンクされているか」の全体像が把握しにくく、引き継ぎや環境棚卸しで困る
• スクリプトの主な処理フロー:
  1. Get-ADDomain でドメインルートを明示的に取得（標準の Get-ADOrganizationalUnit では漏れる）
  2. DistinguishedName を解析して階層ツリーを構築し、gPOptions で継承ブロック有無を判定
  3. gPLink 属性（LDAP文字列）をカスタム関数 Get-Gplink で直接パースしてリンク順序（Order）を抽出
  4. 各OUにリンクされたGPOの表示名・強制（Enforced）・有効/無効（Enabled）・Order を含むツリーをテキストファイルに出力
• 出力例: OU名の横に「[Block Inheritance:継承ブロック]」、GPOに「[Order:1]」「[Enforced:強制]」「[Disabled:無効]」を付与
• 実行要件: RSATの Active Directory モジュールとグループポリシー管理ツール（GPMC）が必要。ADの読み取り権限があれば動作

ImageMagicで画像の一括リサイズ

• URL: https://zenn.dev/8chikuwa3/articles/7691c6e1d076ae
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: オンプレミスのファイルサーバで高解像度写真がストレージを圧迫していた問題に対し、ImageMagickとPowerShellを組み合わせて1MB以上のJPGファイルを一括リサイズするスクリプトを実装した実践記録。ImageMagickのPortable版を使うことで実行環境を汚さず、magick.exeのmogrifyコマンドで縦横最大1280pxにリサイズする。リサイズ後にファイル更新日時が書き変わる問題を回避するため、Exifの撮影日時またはリサイズ前の更新日時をSet-ItemPropertyで復元する処理も組み込まれている。

詳細

• 用途: オンプレファイルサーバの容量逼迫対策として高解像度写真を一括縮小
• 使用ツール: ImageMagick Portable版（実行環境を汚さない）
• 抽出条件: 1MB以上かつ拡張子.jpgのファイル（Get-ChildItemで再帰検索）
• リサイズ設定: magick.exe mogrify -quality 100 -resize “1280x1280>” （縦横どちらかが1280pxに収まるよう縮小）
• 日時復元処理:
  • Exif PropertyItem Id=36867（撮影日時）を取得し、nullまたは"0000:00:00"の場合はLastWriteTimeを使用
  • yyyy:mm:dd形式をyyyy/mm/ddに変換してSet-ItemPropertyで復元
• BatファイルからPowerShell起動してエラーログをリダイレクト保存する構成
• 注意: 画像ファイルによってエラーが発生する場合があり、適宜調整が必要

Active Directory：PingCastleでセキュリティリスクの可視化と対策

• URL: https://zenn.dev/8chikuwa3/articles/7e920ab01b9ea1
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Active Directoryのセキュリティリスクを可視化するフリーツール「PingCastle」の使い方と、実際に検知・対応した脆弱性の事例を紹介している。PingCastleはインストール不要で一般ドメインユーザー権限でも動作し、リスクスコア（0〜100）とルールIDで具体的な指摘を出力する。実際に対応した項目として、krbtgtパスワード長期未変更、AdminSDHolder残留、高度な監査ポリシー未構成、NTLMv1許容、DNSゾーンの非セキュア更新の5点を取り上げている。

詳細

• PingCastle の概要: ADセキュリティリスクをスコア化するツール。インストール不要、一般ドメインユーザー権限で動作、読み取り専用（LDAPクエリのみ）。HTML/XMLレポートを出力
• 実行方法: PingCastle.exe –healthcheck –server mydomain.com またはGUIで「1-healthcheck」を選択
• 対応した5つの検知事例:
  1. A-Krbtgt: krbtgtパスワードの長期未変更。別記事にて安全なリセット手順を解説
  2. A-AdminSDHolder: 特権グループ離脱後も adminCount=1 が残存するアカウントの整理
  3. A-AuditDC: 高度な監査ポリシーの未構成。GPOで13項目（Kerberos認証、ログオン/ログオフ、特権使用等）を「成功」監査に設定
  4. S-OldNtlm: NTLMv1/LM認証が有効のまま。GPOで「NTLMv2応答のみを送信し、LMとNTLMを拒否する」に変更
  5. A-DnsZoneUpdate1: DNSゾーンで非セキュアな動的更新が許可されていた。「セキュアのみ」に変更してDNSポイズニングを防止

part2:「R7年度国・地方ネットワークの将来像の実現に向けた検証事業」から読み解く～僕らの生存戦略～

• URL: https://zenn.dev/8chikuwa3/articles/80ba1c179b9ec1
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 小規模自治体の一人情シス視点から、デジタル庁の「R7年度 国・地方ネットワーク検証事業」の意義とゼロトラストへの移行戦略を読み解いた記事。坂祝町（人口約8,000人）や肝付町（約1.5万人）のような小規模自治体がモデルケースに含まれている点と、GSS共有基盤に乗ることで設計コストを省ける可能性を指摘している。「静的防御から動的・常時検証へ」というゼロトラストの本質と、ファイアウォールとゼロトラストの役割分担（境界防御との共存）についても整理している。

詳細

• 検証事業の注目点: 都道府県だけでなく人口約8,000人の坂祝町（岐阜県）や約1.5万人の肝付町（鹿児島県）が対象。GSS（ガバメントソリューションサービス）共通基盤を活用することで小規模自治体がゼロからの設計を省ける可能性

• ゼロトラストの本質的な転換（Static → Dynamic）:

  • 旧来: ログイン成功後はすべて信頼（静的防御）
  • ゼロトラスト: ログイン後もパッチ適用状況・アクセス時間帯・地域等の振る舞いをリアルタイムで継続検証

• インターネットを味方にする発想: 「閉じる」のではなくクラウドセキュリティサービスに接続して24時間AIと専門家による監視を委託するほうが結果として安全という考え方へのシフト

• FWとゼロトラストの共存（役割分担）:

  • FW（境界防御）: 外部からの明らかな攻撃・不要通信を「玄関」で弾く門番
  • ゼロトラスト（エンドポイント）: 境界をすり抜けたものや内部の横移動を検知する監視カメラと警備員

• 一人情シスが確認すべき3つのポイント:

  1. 自動遮断: パッチ未適用端末がNWに繋ごうとした際に手動でなくシステムが自動切断するか
  2. 通知の可読性: SOCからのアラートが専門用語の羅列ではなく「総務課・佐藤さんのPCでウイルス検知、回収してください」レベルの日本語アクション指示か
  3. ハイブリッドアクセスのUX: 職員がNWを意識せず1つのアイコンクリックでLGWAN業務もインターネット業務もシームレスに使えるか

Microsoft Storeアプリのオフライン展開

• URL: https://zenn.dev/8chikuwa3/articles/823044f9878c90
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: インターネット非接続環境（自治体の三層分離ネットワーク等）で Windows 標準ストアアプリ（付箋・電卓・Snipping Tool 等）をオフライン展開・更新する方法を、Appx/MSIX パッケージの仕様から丁寧に解説した実務向け記事。winget でのオフラインパッケージ取得から、システム権限による Add-AppxProvisionedPackage と一般ユーザー権限による Add-AppxPackage の2層デプロイ設計、PowerShell スクリプトおよび資産管理ツール（SKYSEA 等）向けキックバッチの実装まで網羅している。

詳細

パッケージ取得（インターネット接続環境で実施）:

• winget source update 後、winget download –id –architecture x64 –accept-package-agreements –accept-source-agreements
• Microsoft Entra ID 認証が必要（コマンド実行時に認証画面が表示される）
• Downloads// 配下にパッケージ本体と依存関係・ライセンスファイルがダウンロードされる

代表的パッケージID: Snipping Tool=9MZ95KL8MR0L、付箋=9NBLGGH4QGHW、電卓=9WZDNCRFHVN5、ターミナル=9N0DX20HK701 など

Appx 展開の2ステップ構造:

• Staging: %ProgramFiles%\WindowsApps にファイルをコピー（デバイス単位、ユーザー不要）
• Registration: ユーザーログオン時に各プロファイルへ登録

2層デプロイ設計:

• システム層: SYSTEM 権限 + Add-AppxProvisionedPackage（強制プロビジョニング）
• ユーザー層: サインインユーザー権限 + Add-AppxPackage（ログオンスクリプトで同期実行）

PowerShell スクリプト（AppDeploy.ps1）のポイント:

• -Mode System / -Mode User の引数で分岐
• 共有フォルダ（\Server\AppDeploy\Packages）を自動スキャン、依存関係を自動収集
• -SkipLicense: winget 取得の無料アプリのみ有効。有償 LOB アプリは -LicensePath で明示指定
• 処理結果を共有フォルダのログファイルに出力（コンピューター名・実行ユーザー付き）

キックバッチ（DeployWrapper.bat）の工夫:

• SKYSEA 等が 32bit エージェントの場合、%SystemRoot%\sysnative で 64bit PowerShell を明示指定
• start コマンド不使用で同期実行し、PowerShell の ExitCode を資産管理ツールへ伝播

Office 2024 LTSC バイナリ自動取得＋定期処理スクリプト

• URL: https://zenn.dev/8chikuwa3/articles/86496fe4979b3c
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Office 2024 LTSCのバイナリを毎月パッチチューズデー翌水曜日に自動ダウンロードし、古いビルドを自動パージするPowerShellスクリプトをタスクスケジューラと組み合わせた構成を紹介している。スクリプト内部で「今日が第2火曜の翌水曜か」を判定することで毎日トリガーしても無駄なダウンロードを防ぎ、version型キャストによる安全な世代管理（最新2世代保持）を実現している。SYSTEMアカウントで動作させるためWinHTTPへのプロキシ設定が必要な点も示している。

詳細

• 設計上の工夫点:

  • 業務時間内の数GB通信を避けるためトリガーを「毎日深夜」に設定し、スクリプト内で「第2火曜の翌水曜のみ実行」と判定してスキップ制御
  • ODTが生成するビルドフォルダ（16.0.xxxxx.xxxx形式）を [version]型にキャストして降順ソートし、最新2世代のみ保持して古いバージョンとCABファイルを自動削除
  • ユーザー依存のタスク（パスワード変更で止まるリスク）を避けるため、SYSTEMアカウントで実行
  • SYSTEMアカウントはGUIのプロキシ設定を持たないため、事前に netsh winhttp import proxy source=ie でWinHTTPにプロキシを設定する必要がある

• スクリプトの主な処理（4ステップ）:

  1. 今月の第2火曜日を算出し、翌日（水曜）がターゲット日かどうかを判定
  2. 一致した場合のみ ODT（setup.exe /download config.xml）を実行してダウンロード
  3. 終了コード0（成功）の場合のみパージ処理に進む
  4. Data フォルダ内の 16.0.* ディレクトリを [version]型でソートし、3世代目以降を Remove-Item で完全削除（付随CABファイルも削除）

• タスクスケジューラの補足: デフォルトの priority 7（BELOW_NORMAL）だとダウンロードが遅い場合があり、タスクXMLをエクスポートして priority を 6（NORMAL）に変更すると改善できる

閉域環境でのOffice2024 LTSCの展開

• URL: https://zenn.dev/8chikuwa3/articles/8a226ddcaa0124
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Office2016のサポート期限切れを受け、インターネット非接続の閉域環境でOffice2024 LTSCを展開する手順をまとめた実践記録。ライセンスはCSPで調達し、Active Directoryベースのライセンス認証を使うことでクライアント側の追加操作なしにアクティベーションが完了する。Office展開ツール（ODT）の構成XMLでMSI版Office2016の自動アンインストールも兼ねており、バイナリは共有フォルダに月次ダウンロードして自動更新する構成を取る。展開後に起動が遅くなる問題はグループポリシーの「オンラインコンテンツのダウンロード」設定を未構成に戻すことで解消できた。

詳細

• 対象環境: Office2016（MSI版）からOffice2024 LTSC Standardへの移行、閉域網・ADドメイン環境
• ライセンス認証方式: Active Directoryベースのライセンス認証（KMSホストキーを電話アクティベーションし、クライアント操作不要）
• 展開ツール: Office展開ツール（ODT）＋構成XML（Channel=“PerpetualVL2024”、AllowCdnFallback=“FALSE”）
• RemoveMSI タグを設定することでMSI版Office2016のアンインストールも同時処理
• バイナリはファイルサーバ共有フォルダ（例: \filesv\Office2024）に格納し、UpdatePathを同じパスに指定して月次自動更新
• Standard2024Volume + Access2024Volume の組み合わせと、Standard2024Volume + AccessRuntimeRetail の2パターンのXML構成例を掲載
• 起動遅延の原因: グループポリシー「Office でオンライン コンテンツをダウンロードする接続エクスペリエンスの使用を許可する」が「無効化」になっていたため。「未構成」に変更で改善
• プロキシ環境でも[設定]→[ネットワーク]→[プロキシ]設定を参照してバイナリダウンロードが動作する

Active Directory:OU階層をツリー状テキストに出力

• URL: https://zenn.dev/8chikuwa3/articles/97019af96a3f7b
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Active DirectoryのOU階層構造をPowerShellで解析し、視覚的なツリー状テキストファイルとして出力するスクリプトを紹介している。Get-ADOrganizationalUnit で取得した全OUの DistinguishedName 文字列を解析して階層の深さとソートキーを算出し、インデントを付与してツリーを再構築する。GUIでの俯瞰が難しいAD環境の全体像把握や、構成管理の証跡・引き継ぎ資料として活用できる。

詳細

• 課題: GUIでは全体を俯瞰しにくく、Get-ADOrganizationalUnit のデフォルト出力はフラットなリストで階層が把握しにくい
• スクリプトの処理フロー:
  1. Get-ADOrganizationalUnit -Filter * で全OU情報を一括取得
  2. DistinguishedName をカンマで分割（エスケープされた , は除外）して要素数から階層の深さを取得
  3. 分割した要素を逆順に並び替えてソートキーを生成し、Sort-Object SortKey で階層順に整列
  4. 階層の深さに比例したインデントと |– プレフィックスを付与してツリー文字列を生成
  5. Out-File -Encoding UTF8 でテキストファイルに出力
• 出力例: 最上位OUからサブOUにかけて階層構造がインデントで表現される
• 実行要件: RSATの Active Directory モジュール。読み取り権限のみで動作（管理者権限不要）
• GPO情報も含めた拡張版は別記事（OU階層とGPO適用状況をツリー状テキストに出力）で紹介

Active Directory：adminCount属性と管理者アカウントのチェック

• URL: https://zenn.dev/8chikuwa3/articles/9920944b371db8
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Active DirectoryのAdminSDHolder残留問題について、PingCastleが検出する「A-AdminSDHolder」ルールへの対応手順を解説している。特権グループから外したユーザーに adminCount=1 フラグと継承切れACLが残存し続ける理由を説明し、手動での修正手順と、複数アカウントを対象にした PowerShell 一括クレンジングスクリプトを提示している。スクリプトは現役管理者へのフェイルセーフ検知、クリーンACLのクローン、adminCount属性のクリアを一連の処理としてまとめている。

詳細

• AdminSDHolder の仕組み: 特権グループに所属すると adminCount=1 が設定され、ACL継承が強制的に切断される。グループから外しても自動では元に戻らない
• 手動対応: 属性エディタで adminCount を未設定にし、セキュリティタブの詳細設定から「既定値に戻す」または「継承の有効化」を実施
• PowerShell スクリプト（AdminSDHolder残骸クレンジング統合ツール）の主な処理:
  • テンプレートユーザー（特権を一度も持ったことのない標準ユーザー）からクリーンなACLを取得
  • 処理対象ユーザーが Domain Admins 等の保護グループに現在所属していれば強制スキップ（フェイルセーフ）
  • adminCount=1 の場合のみ Set-Acl でACLを上書きし、Set-ADUser -Clear adminCount で属性を削除
• 対象アカウントが多い場合に一括処理できる設計で、手動操作ミスのリスクを低減できる

AD CSのESC脆弱性チェックと対応

• URL: https://zenn.dev/8chikuwa3/articles/9d16e3fadb70d6
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Active Directory Certificate Services（AD CS）における特権昇格の脆弱性群（ESC1〜16）を、SpecterOps 社のホワイトペーパー「Certified Pre-Owned」に基づいて体系的に解説し、OSS ツール GhostPack/Certify を使った監査手順と対応策をまとめた実践的な記事。証明書テンプレート・PKI コンテナ・CA 本体の3層を個別にスキャンする方法を示し、SAN 任意指定（ESC1）や NTLM リレー（ESC8/11）など致命的な脆弱性への具体的な対応手順を記載している。企業ライセンス問題を避けるため Visual Studio Community ではなく .NET SDK + nuget.exe でのビルド手順を採用している。

詳細

ツール準備:

• GhostPack/Certify は exe 配布なし → .NET SDK + nuget.exe でビルド
• nuget.exe restore Certify.sln → dotnet build -c Release で Certify.exe を生成
• 一般ユーザー権限のドメイン参加端末から安全に実行可（LDAP 読み取りのみ）

3層の監査コマンド:

• テンプレート: Certify.exe enum-templates –filter-enabled –filter-vulnerable –hide-admins（ESC1〜4,9,13 を検出）
• PKI コンテナ: Certify.exe enum-pkiobjects（Domain Users / Authenticated Users が権限を持つ場合は即対応）
• CA 本体: Certify.exe enum-cas –filter-vulnerable –hide-admins（ESC6,7,8,11 を検出）

主要脆弱性と対応:

• ESC1（SAN 任意指定）: テンプレートの無効化 or「Active Directoryの情報から構築する」に変更
• ESC6（CA レジストリの EDITF_ATTRIBUTESUBJECTALTNAME2 有効）: レジストリフラグを無効化
• ESC7（ManageCA 権限の漏洩）: CA のアクセス許可を厳格化
• ESC8/11（NTLM リレー）: IIS で HTTPS 強制・EPA を必須に設定・RPCエンドポイントの暗号化強制。Web 登録サービスが常時不要なら IIS サービス自体を停止

part3:「R7国・地方NW検証事業の経過報告・検証方針の概要」の深堀

• URL: https://zenn.dev/8chikuwa3/articles/a527dc92c8ed6e
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: デジタル庁の「R7年度 国・地方ネットワーク検証事業」の経過報告を詳細に分析し、三層分離モデルの課題とゼロトラスト移行の障壁・アプローチを整理した記事。三層分離が抱える4つの本質的課題（柔軟な働き方への対応困難・運用コスト増大・クラウド活用阻害・サイバー脅威への脆弱性）を自治体プロジェクトの事例を引きながら説明している。技術的障壁・コスト/人材制約・ガバナンス課題・脅威対応の4障壁と、GSS共有基盤の活用、IDaaS/MFA/EDR/ZTNA/DLP等の技術要素別検証結果、宮城・福井・山口・坂祝町・肝付町の導入モデルを紹介している。

詳細

• 三層分離の4つの本質的課題:

  1. テレワーク対応困難（山口県: 閉域網・専用端末でランニングコスト重複）
  2. 運用負荷・コスト増大（宮城県・山口県: 複雑なNW管理の負荷削減が主目的）
  3. クラウド活用阻害（北九州市: インターネット・クラウド利用の利便性が悪い）
  4. サイバー脅威への脆弱性（北九州市: 高度化した攻撃への対策の遅れ）

• 4つの移行障壁:

  1. 技術・アーキテクチャ: 既存オンプレシステムとの接続性（山口県がGSSからオンプレ接続を検証）
  2. コスト・人材: 専門職員不足が深刻。坂祝町（人口約8,000人）は一人情シスが課題として明記
  3. ガバナンス: 住民の「マイナンバー=情報漏洩」という誤解、動的ポリシー管理の負荷（山口県）
  4. 進化する脅威: 北九州市が外部攻撃者/内部不正者に分類して脅威分析

• GSS（ガバメントソリューションサービス）の活用: 1人1台端末・論理的NW分割・DLP・リモートワイプ等の機能を共有基盤として提供。小規模自治体が個別設計の手間を省ける

• 技術要素別検証結果（主要):

  • IDaaS/MFA: 坂祝町でマイナンバー事務系の認証強度を確認
  • EDR/MDM: 北海道で非管理端末からの接続拒否、坂祝町でリモートワイプの所要時間測定
  • ZTNA/CASB: 坂祝町でM365+Zscalerによるアクセス制御、非許可クラウドへのアップロードブロックを検証
  • DLP: GSS利用自治体共通（宮城県等）で機微情報の不正持ち出しをブロック

• 4つの自治体モデル:

  • 宮城県（防災・BCP）: 東日本大震災の教訓を踏まえ衛星回線経由の業務継続を検証
  • 福井県（広域連携）: 県と市町が共同インフラを統合、人材不足を広域でカバー
  • 山口県（コスト最適化）: 岩国市と共同でGSS導入し運用負荷・コスト削減を主目的に検証
  • 坂祝町・肝付町（小規模標準参照）: 一人情シス向けの詳細リスク評価と横展開可能なリファレンスモデル

ボリューム ライセンス認証管理ツール(VAMT)の構築

• URL: https://zenn.dev/8chikuwa3/articles/bbe1ea057e92b6
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: インターネット非接続の自治体クライアント環境でWindows 11ライセンスが失活する問題に対し、VAMT（ボリュームライセンス認証管理ツール）のプロキシ認証を用いた解決手順を紹介している。Windows 11 23H2 → 25H2アップデート時にOEMキーに上書きされてライセンスが外れる現象が発端で、SQL Server Express + ADKでVAMTを構築し、GPOでクライアントのWMIファイアウォール設定を行い、プロキシ経由でアクティベーションを完了する手順を具体的に示している。

詳細

• 発生した問題: Windows 11 23H2 → 25H2 へWSUS経由でアップデートすると、再イメージング権で適用していたプロダクトキーがOEMキーに上書きされてライセンス認証が外れる

• 環境前提: クライアントはインターネット直接接続なし、VAMTサーバー（Windows Server 2022）はプロキシ経由でインターネット接続可能、ドメイン環境

• VAMT構築手順（5ステップ）:

  1. SQL Server Express のインストール（Basicで簡易インストール、インスタンス名をメモ）
  2. Windows ADK から VAMT をインストールし、SQL Server Expressに接続してDB作成
  3. クライアント側: GPOでWMIの受信規則を有効化（対象をVAMTサーバーのIPに絞ることも可）
  4. VAMTでADからコンピュータを検索して追加し、プロダクトキーをインストール
  5. プロキシ認証（Proxy Activate）を実行してアクティベーション完了

• プロキシ認証を選択した理由: クライアントはインターネット非接続、VAMTサーバーはプロキシ経由で接続できる構成のためオンラインでもKMSでもなくプロキシ認証が適切

• 検証結果: 25H2アップデート後にOEMキーが入ってしまった端末に対してプロダクトキーインストール＋プロキシ認証でアクティベーションが正常に完了

ADCSとNPSを使ったEAP-TLSの無線LANを構築

• URL: https://zenn.dev/8chikuwa3/articles/d43ffd966c0283
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Active Directory証明書サービス（AD CS）とネットワークポリシーサーバ（NPS）を組み合わせてEAP-TLSによる802.1X認証の企業無線LANを構築する手順を詳述した記事。PKI証明書の発行・自動配布・自動更新をADと連携させることで、クライアント端末への証明書配布をグループポリシー経由で自動化できる。WPA3エンタープライズ192ビットモードに対応する場合、CAの鍵長とハッシュアルゴリズムをRSA 3072bit / SHA384以上にする必要があり、既存CAを再生成が必要になるケースも解説している。

詳細

• 構成要素: NPS（RADIUSサーバ）、AD CS（エンタープライズCA）、ADドメイン環境
• 構築ステップ:
  1. NPSをADに登録（RAS and IAS Serversグループに追加）
  2. RADIUSクライアント設定（netsh nps add clientコマンドで一括追加可能）
  3. ネットワークポリシー設定: EAP種別「Microsoftスマートカードまたはその他の証明書」を選択、低セキュリティ認証を無効化
  4. エンタープライズCA（ルートCA）をインストール
  5. 証明書テンプレート作成: 「コンピュータ」テンプレートを複製、自動登録権限付与
  6. GPOで証明書自動登録設定: [公開キーのポリシー]-[証明書サービス クライアント – 自動登録]
  7. GPOで無線プロファイル配布
• WPA3 192ビットモード対応条件（全て同時に満たす必要あり）:
  • ルートCA証明書: RSA 3072bit以上 / SHA384以上
  • NPSサーバ証明書: 同上のテンプレートから再発行
  • 証明書テンプレート: キーサイズ3072bit以上、ハッシュSHA384以上
• ドメインコントローラーの証明書ベース認証変更対応: OID（1.3.6.1.4.1.311.25.2）拡張付き証明書が必要。2022年5月以降の更新プログラム適用で対応可能
• 確認コマンド: certlm.mscで信頼されたルート証明・中間証明・個人の証明書配布状況を確認

Windows LAPSを使ってローカル管理者のパスワードを管理

• URL: https://zenn.dev/8chikuwa3/articles/e3be0d5e4cbe8b
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Windows LAPS（Local Administrator Password Solution）を使い、ADドメイン参加端末のローカル管理者パスワードを自動生成・管理する構築手順の記録。キッティング時に共通パスワードが残る問題を解消するため、ADスキーマを更新してOUにパスワード更新権限を付与し、グループポリシーでパスワード複雑度・有効期間・バックアップ先などを設定する。パスワードはActive Directoryに暗号化保存され、承認済み管理者のみ参照可能。認証後アクション機能を使えば、ローカル管理者でログインされた後に猶予時間を経てパスワードリセット＋強制ログオフや再起動を自動実行できる。

詳細

• 検証環境: ADサーバ Windows Server 2016 Datacenter、クライアント Windows 11 Pro 23H2
• Windows Server 2016ではサーバ上でLAPS設定不可のため、クライアントにAD DS + グループポリシーのRSATツールをインストールして操作
• 操作手順:
  1. スキーマ更新: Update-LapsADSchema（フォレスト全体で1回のみ実行）
  2. OU権限付与: Set-LapsADComputerSelfPermission -Identity
  3. グループポリシー設定: [コンピュータの構成]-[管理用テンプレート]-[システム]-[LAPS]
• GPO設定項目:
  • パスワードバックアップディレクトリ: Active Directory
  • パスワードの暗号化: 有効（ドメイン機能レベルWS2016以上で有効）
  • パスワード複雑さ: 大文字+小文字+数字+特殊文字、長さ14、有効期間180日
  • 暗号化パスワード履歴サイズ: 3
  • 管理アカウント名: キッティング時に使用したアカウントを指定
  • 認証後アクション: 猶予8時間後にパスワードリセット＋デバイス再起動
• 確認: ADユーザーとコンピューターでコンピュータオブジェクトのLAPSタブからパスワード確認可能

Karpathy が指摘した「LLMコーディングの失敗パターン」と、コミュニティが作った CLAUDE.md の全貌

• URL: https://zenn.dev/akasara/articles/0d439421852096
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Andrej Karpathyが2026年1月にXで発信したLLMコーディングの失敗パターン（「勝手な前提で走る」「過剰に複雑にする」「関係ないコードを触る」）を受け、開発者Forrest Changがこれを4原則（Think Before Coding / Simplicity First / Surgical Changes / Goal-Driven Execution）として機械可読なCLAUDE.mdに落とし込んだリポジトリが約3.9万スターを集めている。ただしCLAUDE.mdはAnthropicの内部処理で「タスクに関連しない場合は無視されうる」という実態があり、100%の遵守は保証されない。フォーマット・リント・セキュリティチェックなど確実に実行すべき処理にはCLAUDE.mdでなくフックを使うべきというのがコミュニティの定説だ。効果的な運用は「短いCLAUDE.md＋Skill＋条件付きrules＋フック」という複層構成で分離することにある。

詳細

Karpathyが2026年1月26日にXへ投稿した「LLMコーディングの失敗パターン」と、開発者Forrest ChangがそれをCLAUDE.mdに落とし込んだandrej-karpathy-skillsリポジトリ（約3.9万スター、約3.2kフォーク）を一次情報ベースで整理した記事。

Karpathyが指摘した3つの失敗パターン:

• 勝手な前提で走る: 曖昧な指示をサイレントに解釈し確認なしで実装を進める（ジュニア開発者のエラーパターン）
• 過剰に複雑にする: 頼まれていない汎用化・抽象化・柔軟性を追加する
• 関係ないコードを触る: 隣接コードのコメント変更・フォーマット修正・デッドコード削除

Forrest ChangのCLAUDE.md（4原則・約70行）:

• Think Before Coding: 実装前に前提を明示、曖昧ならストップして確認
• Simplicity First: 依頼されていない機能・抽象化・エラーハンドリングは書かない。「シニアエンジニアが複雑すぎると言うか」を判定基準に
• Surgical Changes: 隣接コード・スタイル・デッドコードは触らない。「全変更行がユーザーの依頼に直接たどれるか」が判定基準
• Goal-Driven Execution: 成功基準を先に定義して検証可能にする。「バグを直して」→「再現テストを書きパスさせる」という変換が核心

CLAUDE.mdの実態とAnthropicの公式スタンス:

• セッション冒頭でコンテキストに読み込まれるが「タスクに関連しない場合は無視されうる」というリマインダーがシステムに付与される
• 100%確実に実行すべき処理にはCLAUDE.mdでなくフックを使うべきがコミュニティの定説
• 推奨ファイル長: 200行未満（300行が実質上限）

推奨運用: 恒久ルールは短いCLAUDE.md→条件付きルールは.claude/rules/→長い手順物はSKILL.md→確実に実行すべき処理はフック、という複層構成

Kerberos認証を『会社の入館証』で理解する — ADの裏側で何が起きているか

• URL: https://zenn.dev/akasara/articles/20fddf6fd5797d
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Kerberos認証はWindowsのActive Directory環境でシングルサインオンを実現する仕組みで、「会社ビルの入館証システム」に例えると理解しやすい。KDC（鍵配布センター）が朝イチで発行するTGT（入館証）を使い、各サービスにアクセスするたびにサービスチケットを取得する設計で、パスワード自体はネットワークを流れない。クライアント・サーバ双方が本物かを確認する相互認証、そしてリプレイ攻撃を防ぐ認証子（現在時刻の暗号化）が核心だ。KDCが単一障害点になること、時刻同期（NTP必須）が崩れると全認証が止まること、Kerberoastingなどの攻撃手法がある点は実運用上の重要課題だ。

詳細

Kerberos認証の仕組みを「会社ビルの入館証システム」に例えて体系的に解説した記事。Active Directoryの中核技術として情報処理安全確保支援士やLPICでも頻出。

認証フロー6ステップ:

• AS-REQ: クライアントがパスワードで暗号化した現在時刻をASへ送信（パスワード本体は流れない）
• AS-REP: ASが鍵で復号し本人確認、TGT（KDC鍵で暗号化）とセッション鍵（ユーザー鍵で暗号化）を返す
• TGS-REQ: TGTと認証子（セッション鍵で暗号化した現在時刻）をTGSへ提出してサービスチケット要求
• TGS-REP: TGSがTGTを検証しサービスチケット（ファイルサーバの鍵で暗号化）と新セッション鍵を返す
• AP-REQ: クライアントがサービスチケット+認証子をサービスへ提出
• AP-REP（相互認証モード）: サービスが認証子の時刻+1を暗号化して返し、本物のサーバと証明

主要コンポーネント:

• KDC = AS（本人確認）+ TGS（チケット発行）、ADではドメインコントローラが担当
• TGT有効期限: 通常10時間（ADデフォルト）
• kinit / klist / kdestroy コマンドでLinuxからチケット管理可能

既知の脆弱性・課題:

• Kerberoasting: サービスチケットを傍受してオフラインブルートフォース攻撃が可能
• Pass-the-Ticket: TGT漏洩でなりすまし可能（エンドポイントのLSA Protection等で対策）
• クロックドリフト5分超で認証失敗（NTP必須）
• KDC単一障害点: 冗長構成が必要

nginxを非rootで80番ポートで動かす —Linux Capability入門

• URL: https://zenn.dev/akasara/articles/217e1a13f43004
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Linuxでは従来「root全権か一般ユーザーか」の二択しかなかったが、Capability機能によってrootの特権を約40個に細分化し、必要なものだけを付与できる。nginx等を80番ポートで動かすにはCAP_NET_BIND_SERVICEだけあれば十分で、SUIDビットで全権を与える古いやり方より格段に安全だ。setcapコマンドで個別バイナリに権限を付与し、Effective/Permitted/Inheritableの3セットで管理する。systemd、Docker、Kubernetesいずれもこの仕組みで細粒度のセキュリティ設定が可能になっている。CAP_SYS_ADMINは「新しいroot」と呼ばれるほど広範であり付与は最終手段とすべきだ。

詳細

Linux Capability機能の実践解説。CAP_NET_BIND_SERVICEをPythonバイナリに付与して一般ユーザーで80番ポートにbindするデモをステップ形式で示している。

• rootの全権を約40個の細かい権限に分解するのがCapabilityの本質（Linux 2.2以降）
• setcapコマンドで付与、getcapで確認。=ep（Effective+Permitted）が標準的な付与形式
• 3セット: Effective（今使えるか）、Permitted（使う権利）、Inheritable（子プロセス継承）
• SUID vs Capability比較: SUIDはroot全権、Capabilityは選んだ権限のみ。現代のpingはCAP_NET_RAWでCapability運用に移行済み
• systemdユニットファイルでの設定例: AmbientCapabilities=CAP_NET_BIND_SERVICE / CapabilityBoundingSet=CAP_NET_BIND_SERVICE
• Docker: –cap-drop=ALL –cap-add=NET_BIND_SERVICE でNET_BIND_SERVICEだけ付与
• Kubernetes: securityContext.capabilities.drop/addで指定（セキュリティ審査の頻出ポイント）
• CAP_SYS_ADMINは実質rootと同等の広範な権限（マウント・sethostname等40以上のサブ機能）であり付与は厳禁
• Capabilityはコピー時にxattrとして扱われるため、cp -a や tar –xattrsで保持が必要
• /proc/self/statusのCapフィールド、capsh –decodeでデコード可能
• 監査: sudo getcap -r / 2>/dev/null でシステム全体のCapability付きファイルを確認

OpenClawからClaude Codeを操縦する実践ガイド

• URL: https://zenn.dev/akasara/articles/2b6db248c05792
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: OpenClawをオーケストレータとしてClaude Codeを作業員として動かす際の設計原則は「管理職と作業員の責務分離」にある。CLI（claude -p のワンショット）、SDK（query()/ClaudeSDKClient）、Skills、Agents、Hooks、MCPという12パターンの操作方法を組み合わせて無人運用を構築できる。安全な自動化の基本は「–toolsで絞り→–allowedToolsで無人化→–max-budget-usdで上限設定」の三段構えで、並列実行には-w/–worktreeによる隔離が必須だ。OpenClawからの出力は–output-format jsonで構造化し、MCP双方向連携ではclaude mcp serveでClaude Code自体をMCPサーバとして公開することも可能だ。

詳細

OpenClawオーケストレータからClaude Codeを操作する12パターンの全体像と安全な運用設計を解説した実践記事。

12パターンの操作方法（3方向）:

• タスクを投げる: claude -p（ワンショット）/ –resume/-r（セッション再開）/ –continue/-c（直前会話継続）/ –fork-session（枝分かれ）/ –mcp-config（MCP接続）/ -w/–worktree（隔離実行）
• 結果を受け取る: stdout JSON（–output-format json）/ Hooks（Stopイベント）/ ファイル出力（MD/JSON）
• 双方向: .mcp.json / claude mcp serve / SDK MCP（@tool）

cron向け安全テンプレートの要素:

• timeout 300 でタイムアウト設定
• –output-format json + –json-schema で構造化出力
• –permission-mode plan で読み取り専用分析を標準化
• –tools “Read,Grep,Glob” + –allowedTools で許可ツールを絞り込み
• –max-turns 5 + –max-budget-usd 2.00 で上限設定
• –no-session-persistence で永続化を切る

並列実行と隔離:

• -w/–worktreeで/.claude/worktrees/に隔離環境を作成
• 複数worktreeが独立したgit worktreeとして動くためファイル衝突なし・mainブランチ汚染なし

Python SDK:

• query()スタイル: async for msg in query(…)でストリーム取得するワンショット
• ClaudeSDKClientスタイル: セッション維持でマルチターン（分析→修正→テストの連続WFに最適）
• @tool + create_sdk_mcp_server() でOpenClawの機能をClaude側にツールとして動的登録可能

段階的導入推奨: cron1本 → worktree並列 → Skills/Hooks → SDK統合

Claude Code × Chrome で調査書・手順書をまるごと自動生成する

• URL: https://zenn.dev/akasara/articles/34cbb34e29475b
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 「claude –chrome」の1コマンドでClaude CodeとChromeを連携させると、ブラウザのページ遷移・クリック・フォーム入力・スクショ取得をAIに委譲でき、調査書や手順書の生成を自動化できる。既存のブラウザセッションをそのまま共用するためログイン画面をAIが突破する必要がなく、CAPTCHA等に到達した時点で人間に制御を戻す設計だ。Google フォームでのデモでは34枚のスクショを撮影しながら約12分で手順書を生成した。コンテキスト消費が重い点はサブエージェントへの分離で吸収でき、親セッションには最終テキストのみが返る構造が有効だ。ただし対応ブラウザはChrome/Edgeのみで、BraveやWSL環境では動作しない。

詳細

Claude Code × Chrome連携（claude –chrome）を使ってブラウザ操作を自動化し、調査書・手順書を生成する実践記事。Google フォーム作成の12分デモを含む。

アーキテクチャと機能:

• Claude in Chrome拡張をMCPで接続する連携機能（2025年後半ベータ提供開始）
• ページ遷移・クリック・フォーム入力・スクショ取得・GIF録画に対応
• DevToolsのconsole log・ネットワークリクエスト読み取りが可能
• ログインセッションをそのまま共用。CAPTCHA・ログイン画面で自動停止し人間に委譲
• 対応ブラウザ: Chrome/Edgeのみ（Brave/Arc/他Chromium派生/WSL非対応）
• 対応プラン: Pro/Max/Team/Enterprise

デモ実測値（Google フォーム5問作成→共有リンク取得→手順書化）:

• 所要時間: 12分14秒
• スクショ: 34枚（約1.5MB）
• runbook.md: 約90行
• runbook.docx: 332KB（画像12枚埋め込み）
• 成果物はそのまま社内配布ルートに乗せられる形式

コンテキスト管理の注意点:

• スクショはbase64 JPEGとして会話履歴に累積し、コンテキスト消費が重い（Issue #27869で議論中）
• 対策1: セッションを短く切り、runbook出力後は/exitで終了
• 対策2: サブエージェントに分離（独立コンテキスト・親には最終テキストのみ返す）
• サブエージェント定義はtools: [claude-in-chrome, bash, write, read]を指定

活用ユースケース:

• SaaS新規登録・初期設定手順書の自動生成
• クラウドコンソール（GCP/AWS等）設定手順書
• UI変更後の既存手順書の鮮度チェック
• 複数サイト横断の料金・機能比較調査書

【2026年4月更新版】Claude Code 完全ガイド — インストールからAgent Teamsまで

• URL: https://zenn.dev/akasara/articles/4fbf28fcfcd836
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude Codeはターミナル・デスクトップ・Web・IDE・Routinesまで揃えた「AIオペレーションプラットフォーム」へと進化しており、2026年4月時点の機能を包括的にまとめた記事。インストールから料金、スラッシュコマンド、CLAUDE.md設計、Extended Thinking・Effort Level、Hooks、MCP、Skills、Routines、Agent Teamsに至るまで体系的に整理されている。Opus 4.7ではxhigh Effort Levelが追加され、1時間プロンプトキャッシュやBatch APIによるコスト最適化手法も詳述されている。競合との比較やエンタープライズ運用のアンチパターンも網羅している。

詳細

• インストール方法: curl/Homebrew/npm/PowerShellの4種、claude doctor/–versionで確認
• 料金体系（2026年4月）: Pro $20、Max 5x $100、Max 20x $200、Team Premium $125/席/月
• APIモデル価格: Opus 4.7は入力$5/出力$25、Sonnet 4.6は入力$3/出力$15、Haiku 4.5は入力$1/出力$5（いずれも100万トークンあたり）
• コスト最適化8選: 3層モデル戦略（Haiku/Sonnet/Opus）、1時間プロンプトキャッシュ（ENABLE_PROMPT_CACHING_1H=1）、/compact、Batch API 50%オフ等
• Effort Level（Opus 4.7）: low/medium/high/xhigh（デフォルト）/maxの5段階。xhighは複雑なリファクタや難バグ向け
• デスクトップアプリ（2026年4月14日リリース）: マルチセッションサイドバー、ドラッグ&ドロップペインレイアウト、統合ターミナル、インラインファイルエディタ、Cmd+;でサイドチャット分岐
• パーミッションモード: Normal/Auto-Accept/Auto Mode/Plan/Delegate/dontAsk/bypassPermissions
• CLAUDE.md推奨サイズ: 60〜80行、最大500行。ビルドコマンド・コード構造・ワークフロー規約・環境の癖のみ記載
• 主要スラッシュコマンド: /recap（セッション復帰サマリー）、/rewind（巻き戻し）、/effort（Effortスライダー）、/ultrareview（Opus 4.7厳格レビュー）、/teleport（ローカル⇔Web移行）等
• Agent Teams（実験的）: フロントエンド/API/マイグレーション担当のように作業分割し並列処理

OpenClawで「自己強化エージェント」を構築する手順書 ─ Heartbeat × 監督役エージェントで運用が勝手に改善される仕組み

• URL: https://zenn.dev/akasara/articles/52dc506100f7ad
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: OpenClawのHeartbeat機能と監督役エージェント（ops/coach）を組み合わせ、使えば使うほど運用が自動改善される「自己強化ループ」を構築する手順書。実務担当（main）は実行・報告のみ、監督役（ops/coach）はHeartbeatで定期評価・改善提案・ログ記録のみと責務を完全分離し、1回のHeartbeatで改善ログへの追記は最大1件に制限するのが核心となる設計方針。人間が提案→レビュー→適用→検証の4段階ゲートキーパーとして機能し続けることで安全性を担保する仕組みになっている。SOUL.md・HEARTBEAT.md・memory/improvements.mdのテンプレート一式とOpenClawへのプロンプトをそのまま使える形で提供している。

詳細

• アーキテクチャ: main（実行・事実報告のみ）→ handshake.md → ops/coach（Heartbeatで評価・1件追記）→ improvements.md → 人間レビュー → decisions.md
• SOUL.md: 全体の憲法。最小権限・設定変更禁止・秘密情報記録禁止・短く報告。短く固定し月1回程度のみ変更
• HEARTBEAT.md: ops/coachチェックリスト。繰り返す摩擦（同じエラー2回・前提不足・不明確プロンプト・過剰出力）を検出し、1件のみimprovements.mdに追記またはHEARTBEAT_OKを返す
• improvements.mdのエントリ形式: Symptom/Root cause（config/prompt/procedure/permission/tool/external 6分類）/Fix（最小変更）/Preventive check（1行）/Expected impact/Risk & rollback/Status
• Heartbeat設定: ~/.openclaw/openclaw.json にevery（“30m”）・target（“last”）・activeHours（09:00〜23:00）を設定。coachエージェントだけに適用
• ベストプラクティス7箇条: 1Heartbeat=1改善、提案と適用の分離、SOUL.mdを短く固定、mainは反省しない、改善ログに再発防止チェック1行必須、activeHoursで夜中の動作を防ぐ、テンプレートは自作・レビュー前提
• セキュリティ: config.apply/patchは人間承認フロー、secrets/tokensはメモリファイルに書かない、improvements.mdはappend-only
• サプライチェーンリスク: HEARTBEAT.mdやskillsの外部配布は攻撃面になり得るため、外部テンプレートは必ず中身を確認してから使う

MCP（Model Context Protocol）最新仕様まとめ — OAuth 2.1認可フローとAPI Gateway連携の実践例

• URL: https://zenn.dev/akasara/articles/5a089bf8294d27
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: MCP（Model Context Protocol）の2025-11-25版仕様の概要・OAuth 2.1認可フロー・Azure API Managementを使った実践構成を体系的に整理した記事。2025-11-25版ではTasks（非同期タスク）・Sampling with Tools・OIDC Discovery 1.0必須サポート・CIMD（クライアント登録の新推奨方式）・Extensionsフレームワークが追加された。2025年6月版以降でMCPサーバーはリソースサーバー専任に分離されOAuth 2.1の役割分担が明確化しており、エンタープライズ向けにはCross App Access（SEP-990）で企業IdPが接続を可視化・制御できる拡張も加わった。月間SDK DL数は約9,700万回、MCPサーバー数は16,000以上と普及は急速に進んでいる。

詳細

• MCPの基本: JSON-RPC 2.0ベース。Tools/Resources/Promptsの3概念。Host→Client→Serverの3層アーキテクチャ
• 仕様変遷: 2025-03-26（OAuth 2.1初期導入・Streamable HTTP）→2025-06-18（MCPサーバーをResource Server専任に分離・RFC 8707必須）→2025-11-25（Tasks実験的・OIDC Discovery必須・CIMD・Extensions）
• 2025-11-25版主な変更:
  • Tasks（SEP-1686、実験的）: 長時間リクエストの状態追跡・ポーリング非同期プリミティブ
  • Sampling with Tools（SEP-1577）: サーバーがサンプリングリクエストにツール定義を含め、server-side agent loopが可能に
  • CIMD（SEP-991）: DCRに代わる推奨クライアント登録方式
  • Cross App Access/XAA（SEP-990）: エンタープライズIdPがMCP Client⇔Server接続を可視化・制御（オプション拡張）
  • PRMディスカバリー（SEP-985）: WWW-Authenticateヘッダーはオプション化、.well-knownへのフォールバックが標準
• OAuth 2.1のロール対応: MCP Client=OAuth Client、MCP Server=Resource Server、外部IdP=Authorization Server
• セキュリティ要件: PKCE必須（S256推奨）、Token Audience Validation（RFC 8707）、トークンパススルー禁止（Confused Deputy攻撃防止）、リダイレクトURIはlocalhost/HTTPSのみ
• Azure APIM実践構成: APIM=OAuth Resource Server兼PRM提供、Entra ID=AS/IdP、Azure Functions=MCPサーバー（セキュリティコードなし）。APIMでAuthorizationヘッダーを削除しclaimをカスタムヘッダーに変換して転送
• 採用状況: SDK月間DL数約9,700万回（Python+TypeScript）、MCPサーバー数16,000以上、対応クライアント: Claude・ChatGPT・Cursor・Gemini API/SDK・GitHub Copilot・VS Code

Claude Code vs Gemini CLI ｜ 実務的な使い分けガイド【2026年版】

• URL: https://zenn.dev/akasara/articles/8387058078309d
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude CodeとGemini CLIは「どちらか一択」でなく、タスクの性質に応じて役割を分担するハイブリッド構成が実務で定着しつつある。Composioの実測比較では同一タスクでClaude Codeが所要時間77分・コスト4.80ドルでGemini CLIの122分・7.06ドルを上回ったが、大規模コードベースの全体走査ではGemini CLIの1Mコンテキストを活用して探索させ、分析結果をClaude Codeに引き渡す構成がコスト合理的だ。Hacker Newsのコミュニティでは「Geminiで広く拾い、Claudeで深く掘る」という分担が繰り返し言及されており、探索→実装分割型・カスタムスラッシュコマンド統合型・ヘッドレス並行型・コスト最適化型の4パターンが標準的とされる。

詳細

Claude CodeとGemini CLIのハイブリッドワークフローを、実測ベンチマーク・事例・コミュニティ観測・価格比較を交えて解説した記事。

Composioによる同一タスク実測比較（DEV Community出典）:

• Claude Code: 所要時間77分、コスト$4.80、入力トークン260.8K、1回で成功、テスト構造化済み本番品質
• Gemini CLI: 所要時間122分、コスト$7.06、入力トークン432K、複数回試行、テスト散乱

3つのハイブリッド事例:

• Flutter GetXバグ修正（byjos.dev）: Gemini CLIで1M+トークンのコードベース走査→原因絞り込み→Claude Codeで実装→GeminiでFinalレビュー
• フロントエンドUIリデザイン（paddo.dev）: ~/.claude/commands/gemini.mdにカスタムスラッシュコマンドを自作し、Claude内からGemini CLIを呼び出す2層構造を構築
• ヘッドレス並行型: Claude Code内から gemini -p “” の1行でGeminiをサブルーティン化

タスク別推奨:

• Gemini CLI優位: 大規模コードベース全体走査（1Mコンテキスト標準）、Web検索・CVE確認・changelog調査、スクリーンショット解析、Google Cloud/GKE調べもの、試作・小スクリプト（無料枠60req/min・1,000req/day）
• Claude Code優位: 複雑な実装・リファクタ・テスト生成、アーキテクチャ判断・セキュリティレビュー、MCP連携、マルチファイルリファクタ

料金・仕様比較（2026年4月11日時点）:

• Claude Code: Pro $20/月〜。コンテキスト対応モデル・プランで最大1Mトークン
• Gemini CLI: 無料枠あり（60req/min・1,000req/day）。Apache 2.0オープンソース

SIer/コンサルの文書仕事を変えるClaude for Word徹底解剖

• URL: https://zenn.dev/akasara/articles/9d95f53755f1b4
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 2026年4月10日にパブリックベータ公開されたClaude for Wordは、WordのサイドバーにClaudeが常駐し、既存の書式やスタイルを維持したまま変更履歴として編集を行うOfficeアドインだ。Microsoft Copilotが段落を丸ごと書き換えるのに対し、Claude for Wordは差分が明確で変更箇所の厳密な確認が必要な法務・監査書類に対応できる。コメント駆動編集（大量コメントへの一括対応）、意味ベース検索、アプリ横断データ連携（Excel/PowerPoint連携）など実務に即した機能が揃う。現時点ではTeam/Enterpriseプランのみ対応、審査ログが未実装なため機密情報を扱う金融・医療案件での導入は慎重な判断が必要だ。Claude Codeとの「二階建て」運用（Code で初稿生成→Word で対話編集）が最も効率的とされる。

詳細

Claude for Word（Wordアドイン）の機能を、SIer・コンサル業務での活用観点から網羅的に解説した記事。2026年4月10日パブリックベータ公開。

主要機能8つ:

• 変更履歴（Tracked Changes）モード: Claudeの編集が標準の変更履歴として残り、人間が1件ずつ承認/却下できる（Copilotとの最大の差別点）
• コメント駆動編集: 大量のレビューコメントを一括で読み取り、変更履歴として自動修正し返信を書き込む（「Work through my open comments」等のプロンプトで実行）
• テンプレート書式の維持: 見出し・段落・表のスタイルを壊さずに文章を生成
• 文書QA（引用リンク付き）: 長文文書に対して質問し、クリック可能な引用リンク付きで回答
• 意味ベース検索（Semantic Navigation）: キーワード完全一致ではなく意味で関連箇所を探索
• 取引先からの赤入れ要約: 変更履歴付き文書の修正内容を要約し交渉上重要な箇所をピックアップ
• 一貫性自動チェック: 用語のブレ・壊れた相互参照・番号ズレを検出
• アプリ横断データ連携: Excel/PowerPoint版と同一チャット画面でOffice3アプリを横断して作業可能

利用環境:

• Team/Enterpriseプランのみ（現時点）
• Windows/Mac/Web版Word対応。Word 2016/2019（買い切り版）・iPad/Android版は非対応
• 搭載モデル: Sonnet 4.6（高速）とOpus 4.6（高度）を切り替え可能

セキュリティ上の注意点:

• プロンプトインジェクションリスク: 外部ファイルに仕込まれた隠し指示をAIが実行する可能性
• データ保存期間: 30日以内に自動削除。Wordを閉じると会話履歴リセット
• 監査ログ未実装: ベータ版段階のため管理者が利用状況を確認できない

SIer/コンサル向けユースケース10選（基本設計書・試験仕様書・顧客コメント対応・RFP回答・運用手順書・セキュリティ監査回答・障害報告書・契約書確認・技術資料・議事録清書）を具体的に列挙している。

Claude Designが来た日 ─ Webデザイナーとフロントエンドの仕事はどこまで削られるのか

• URL: https://zenn.dev/akasara/articles/ab24affd00d788
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 2026年4月にAnthropicがresearch previewとして発表したClaude Designは、自然言語でHTML/CSS/JavaScriptの動くプロトタイプ・スライド・LPを生成しClaudeCodeにハンドオフできる設計ツールだ。Figma Makeやv0との最大の違いは「Claude Codeへの構造化ハンドオフ」が最初から出口として用意されている点で、単なるデザイン画像生成でなくコード駆動のプロトタイプを出力する。Anthropicの CPO Mike Krieger氏（元Instagram共同創業者）がFigmaの取締役を辞任したことや発表前後でのFigma・Adobe株価下落が示すように、「最初にFigmaを開くのではなくClaudeに話しかける」という入口の変化が業界に与えるインパクトは大きい。Brilliant社は20プロンプト必要だった複雑ページを2プロンプトで再現できたと報告している。

詳細

Claude Design（2026年4月 research preview）の機能と、Webデザイナー・フロントエンドエンジニアへの影響を実体験ベースで分析した記事。架空ツール「Opus Canvas」のLPをCloudflare Pagesにデプロイしてレポートしている。

主な機能:

• テキスト/画像/DOCX/PPTX/XLSX/コードベース参照などを入力として動くHTML/CSS/JSプロトタイプを生成
• 会話・インラインコメント・直接編集・カスタムスライダーで反復的に詰める操作モデル
• チームのコードベースやデザインファイルを読ませてデザインシステムを自動適用
• 出力: 社内URL・Canva/PDF/PPTX/standalone HTMLでエクスポート可能
• Claude Codeへの「ハンドオフバンドル」として引き渡し可能（design intentを含む）

競合との差別点:

• v0: React+Tailwind+shadcn/uiのUIコンポーネント生成が強いがClaude Codeハンドオフは劣る
• Lovable: Supabase統合のフルスタックMVPに強い
• Figma Make: Figma内資産活用が強いがClaude Codeとの接続はClaude Designが強い
• Google Stitch / Figma AI: 既存ツール内AI統合が中心

業界インパクトの観点:

• 発表前後でFigma・Adobe・Wix・GoDaddy株価が下落
• AnthropicのCPO Mike Krieger氏（元Instagram共同創業者）がFigma取締役を辞任、SEC開示
• Brilliant社事例: 20プロンプト→2プロンプトで同等の複雑ページを再現（公式発表前面に掲載）

提供条件:

• Claude Pro/Max/Team/Enterprise向け（段階的ロールアウト中）
• Enterpriseはデフォルト無効、管理者が有効化必要
• プロ内の使用量を消費。足りなければextra usage

ChatGPTの回答、半分ウソかも？─ AIの嘘を見抜く「3ステップ検証」完全ガイド

• URL: https://zenn.dev/akasara/articles/b6f09f71e2fb23
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: AIハルシネーションの実被害事例（弁護士が架空判例を繰り返し提出しクライアントが自動敗訴した事案等）を起点に、3段階の検証フローを解説した記事。Phase 1は同じAIに回答者とチェック係を分けて確信度を分類させ、Phase 2は別モデルに批判役をさせることで同一モデルの盲点を補い、Phase 3は取り返しのつかない場面のみ一次情報の出典紐付けを行う。オープンドメインでのハルシネーション率はOpenAI o3のSimpleQAで51%、Grok-3のニュース出典特定で94%誤答という数値が示されており、モデルが賢くなるほど「創作」が上手くなる逆説的リスクも整理されている。

詳細

• 被害事例: フェルドマン弁護士がAI架空引用を裁判所警告後も繰り返し→クライアントに自動敗訴判決（Reason, 2026年2月）。AI Hallucination Cases Databaseには905件超の法的事案が記録
• ハルシネーション率データ（要約タスク・Vectara HHEM）: Finix S1 32B 1.8%、Gemini 2.5 Flash Lite 3.3%、Microsoft Phi-4 3.7%
• ハルシネーション率データ（オープンドメイン）: OpenAI o3のPersonQA 33%、SimpleQA 51%、o4-miniのSimpleQA 79%、Grok-3のニュース出典特定 94%、ChatGPT総合 35%
• なぜ賢いモデルほどリスクが高いか: 推論能力強化により存在しない論理や事実を「推論」で捏造する。OpenAI o3はSimpleQA正答率49.0%
• Phase 1プロンプト設計: 「結論→理由→手順→注意点」で回答させた後、同じチャットで「確実/たぶん/不明」の3カテゴリに分類させる。数値・固有名詞・断定表現を重点チェック
• Phase 2の必要性: 同じAIは同じ学習データ→同じ盲点。別モデルへ「性格の悪い批評家」として間違いの条件3つ・例外3つ・最も危ない断定・一般人が信じやすい誤りを指摘させる
• Phase 3の適用場面: クライアント提出資料・契約書・法的文書・医療安全情報のみ。社内ブレスト等はPhase 2まで
• 多数決が機能しない理由: 主要LLMは類似した学習データで訓練され同じ間違いをする傾向。全員が同方向に誤る可能性がある
• 理論的根拠: Xu et al.「Hallucination is Inevitable」（2024）、Banerjee et al.「LLMs Will Always Hallucinate」（2024）でハルシネーションの完全排除は原理的困難と示されている

Claude Code（開発）× OpenClaw（運用）の責務分離 ── CLAUDE.md 肥大化問題とベストプラクティス

• URL: https://zenn.dev/akasara/articles/b80fe3c8cc8569
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude Code（開発）とOpenClaw（24時間常駐の汎用AIエージェント）を併用する際に、CLAUDE.mdに両者の指示が混在すると性能が落ちるという問題を扱った記事。解決策として、開発専用のCLAUDE.mdには300行未満・開発直結の指示のみを残し、OpenClaw固有の設定はAGENTS.md・SOUL.md・IDENTITY.mdへ分離することを推奨している。コンテキストウィンドウの有限性と、Agent Teams使用時のトークン乗数的増大が分離を迫る主な理由として挙げられている。コードスタイルはリンターへ委譲し、ドメイン知識はskillsへ移行するのがベストプラクティスとされる。

詳細

• Claude CodeとOpenClawの違い: Claude CodeはCLI・セッション単位、OpenClawはメッセージングアプリ・常駐デーモン・長期メモリ持ち
• CLAUDE.mdに含めるべきもの: ビルド/テストコマンド、コード構造、ワークフロー規約、環境セットアップ、プロジェクト固有の注意点
• CLAUDE.mdに含めないもの: 人格設定→IDENTITY.md、セッションプロトコル→AGENTS.md、メモリシステム→AGENTS.md、高リスク操作ゲート→SOUL.md、コードスタイルガイド→ESLint等
• 推奨サイズ: 300行未満。「この行を削除したらClaudeがミスするか？」と問い、Noなら削除
• Agent Teams時の注意: 各チームメイトはCLAUDE.mdを自動読み込みするためCLAUDE.mdが太るほどコストが乗数的に膨らむ
• ファイル階層戦略: CLAUDE.mdはポインタのみ置き、詳細はagent_docs/・.claude/skills/に分離。@agent_docs/service_architecture.mdのように参照
• 移行手順: wc -l CLAUDE.md→/contextで使用量確認→セクション分類→移行後に/contextで削減確認
• コンテキストエンジニアリングの原則: スタティックコンテキスト最小化、ダイナミックコンテキスト（skills・サブエージェント）活用、確定的処理はLLMに任せない、ポインタ>コピー
• 参考: 末尾に書籍（西見・吉田・大嶋著「実践Claude Code入門」、平川著「Claude CodeによるAI駆動開発入門」）が紹介されているが、内容の実質部分は独立している

Claude Code の Dynamic Workflows を理解する — Subagents / Skills との違いと実務での使い

• URL: https://zenn.dev/akasara/articles/ccfb2f7a5174e0
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude CodeのDynamic Workflows（2026年5月28日にresearch previewとして追加）の仕組みと実務での使い方を整理した記事。大きなタスクを分割するオーケストレーション用JavaScriptスクリプトをClaudeが生成し、複数のサブエージェントを並列起動して相互検証させた後に結果だけを返す設計で、コンテキスト圧迫・計画の会話依存・再利用困難という従来のSubagentsの限界を緩和する。起動方法は/deep-research・「workflow」キーワード・/effort ultracode の3種類で、ワークフローの保存と再利用も.claude/workflows/配下で可能。

詳細

• 追加時期: 2026年5月28日、Claude Opus 4.8と同時。現時点ではresearch preview
• 必要バージョン: Claude Code v2.1.154以降。/configからDynamic workflowsを有効化（Proプランは手動有効化が必要）
• 本質: 計画をJavaScriptスクリプトとして持つことで「広い対象の分割・独立した観点での調査・別エージェントによる反証」を実現。中間結果はスクリプト変数に保持され、Claudeのコンテキストには最終結果のみ返る
• 従来Subagentsの3つの限界: コンテキスト圧迫（中間結果がすべて積み上がる）・計画が会話に縛られる・再利用しづらい
• 起動方法3種:
  1. /deep-research: 最手早く試せる組み込みワークフロー。複数角度でWeb検索・相互クロスチェック・引用付きレポート
  2. プロンプトに「workflow」を含める: 単発タスクをワークフロー化。alt+wで無効化可能
  3. /effort ultracode: xhigh reasoning effort + 自動ワークフロー判断。普段使いはトークン消費大
• 権限: サブエージェントはacceptEditsモードで動作（ファイル編集自動承認）。シェルコマンド・WebフェッチはallowlistにないとPrompt表示
• /workflows で進行確認（エージェント数・累計トークン・経過時間・状態）。p=一時停止/再開、s=スクリプト保存、r=エージェント再起動
• ワークフロー保存先: .claude/workflows/（プロジェクト全員と共有）または~/.claude/workflows/（個人全プロジェクト）
• 向いているタスク（2つ以上で検討価値あり）: 対象が広い・観点が複数・独立レビューが必要・手順を再利用したい

Anthropic、Opus超えの新ティア「Claude Fable 5」を一般公開 — Mythos級モデルがついに誰でも使える

• URL: https://zenn.dev/akasara/articles/ce6287e39a9a52
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: AnthropicがOpusの上位に位置する新ティア「Claude Fable 5」を一般公開したという発表を詳細に解説した記事。Mythos级モデルを安全分類器付きで一般公開したもので、危険領域（サイバーセキュリティ・生物学）のリクエストのみをClaude Opus 4.8に自動ルーティングする設計により、95%以上のセッションでは制限を体感しない。SWE-Bench Proで80.3%（Opus 4.8比+11%）など、エージェント型コーディング指標での伸びが顕著。Mythosクラスの利用には全トラフィックへの30日間データ保持が義務化されており、ZDR契約を持つ企業にも適用される点が重要な変更事項。

詳細

• Claude Fable 5: Mythos級の能力に安全分類器を付与した一般公開モデル。モデル文字列: claude-fable-5
• Claude Mythos 5: Project Glasswingパートナー（AWS・Microsoft・Apple・CrowdStrike等約50社）と選定された生物学研究者のみ
• 安全アーキテクチャ: サイバーセキュリティ・生物学・蒸留の高リスクリクエストをClaude Opus 4.8へ自動ルーティング。作動するのは全セッションの5%未満
• 主要ベンチマーク（Fable 5 / Mythos 5）:
  • SWE-Bench Pro: 80.3%（Opus 4.8: 69.2%）
  • FrontierCode Diamond: 29.3%（Opus 4.8: 13.4%）
  • OSWorld-Verified: 85.0%（Opus 4.8: 83.4%）
  • Humanity’s Last Exam（with tools）: 64.5%（Opus 4.8: 57.9%）
  • Terminal-Bench 2.1: 88.0%（Opus 4.8: 82.7%）
• API価格: 入力$10 / 出力$50（per 1M tokens）。Mythos Previewの半額以下、Opus 4.8の約2倍
• サブスク: 6/22までPro/Max/Team/Enterpriseに追加料金なし。6/23以降はクレジット制
• 提供クラウド: Amazon Bedrock・Claude Platform on AWS・Microsoft Foundryで即日GA
• 重要変更: Mythosクラス利用には全トラフィックへの30日間データ保持が義務化。ZDR契約を持つ企業にも適用。Anthropicは「訓練には使用せず、ジェイルブレイク防御と誤検知低減のみ」と説明
• Stripeの事例: 2ヶ月以上の見積もりがあった大規模Rubyコードベース移行を数日で完了
• 発表タイミング: AnthropicのSEC非公開IPO申請の数日後

Claude Code × Codex プラグイン (openai/codex-plugin-cc) で堅牢なAIクロスレビュー環境を

• URL: https://zenn.dev/akasara/articles/d1303ce284a33f
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 2026年3月30日にリリースされたopenai/codex-plugin-ccは、Claude CodeからOpenAI Codexを呼び出してコードレビューやバグ修正を委譲できるプラグインだ。設計思想は「Claude Codeが実装し、Codexが独立したレビュアー」という責務分離で、/codex:review（読み取り専用・差分レビュー）、/codex:adversarial-review（認証フローや破壊的変更への設計批判）、/codex:rescue（バグ修正委譲）の3コマンドが核心だ。常時自動レビューゲートをオンにするとClaude-Codex間の無限ループが発生しAPIコストを浪費するリスクがあるため基本はオフにし、高リスク変更の直前にのみ手動で回す運用が推奨される。rescueはスコープを狭く・成功条件を明確に指定するのがコツだ。

詳細

2026年3月30日リリースのopenai/codex-plugin-ccを使いClaude Code内からOpenAI Codexをレビュアーとして呼び出す実践ガイド。

導入手順:

• /plugin marketplace add openai/codex-plugin-cc
• /plugin install codex@openai-codex → /reload-plugins → /codex:setup
• npm install -g @openai/codex でCodex CLI導入
• 認証情報保存先はauth.jsonでなくOSのKeyring推奨（~/.codex/config.toml に cli_auth_credentials_store = “keyring” と設定）
• /agentsコマンドでcodex:codex-rescueが見えれば準備完了

4つの鉄則:

• 実装はClaude、査読はCodex（非同期）: /codex:review –background または /codex:review –base main –background
• 高リスク変更には adversarial-review: 認証フロー変更・KubernetesのPVC変更・DBマイグレーション前に /codex:adversarial-review –base main –background で設計判断を批判させる
• rescueは条件を狭く明確に: smallest safe patch・無関係リファクタ禁止・対象ファイル明記・成功条件（テスト通過等）明記の4条件を満たすプロンプトで投げる
• 常時Review Gateは基本オフ: Stop hookベースの自動ゲートは往復ループのリスクあり

.codex/config.toml（プロジェクト固有設定）:

• model = “gpt-5.4-mini”
• model_reasoning_effort = “high”（maxではなくhighから始めることを推奨）

CLAUDE.mdへの運用ルール記載推奨内容:

• Codexはレビュアー・調査者であり主実装者にしない
• まとまった機能追加後は/codex:review –backgroundを実行
• 認証・シークレット・権限・並行処理・課金等の高リスク変更時は/codex:adversarial-review –backgroundを実行
• rescueはテスト可能な狭いタスクにのみ明確な成功条件を添えて使用

Claude Codeの新機能 /ultrareview とは何かーエージェント集団によるマージ前の深層レビュー

• URL: https://zenn.dev/akasara/articles/d77027b4d0a10a
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude Code v2.1.86で追加されたresearch preview機能「/ultrareview」は、クラウド上のサンドボックスで複数のレビューエージェントを並列実行し、ブランチやPRのバグをマージ前に検出する。ローカルの/reviewと異なり「独立した再現・検証ステップ」があるため、誤検知率1%未満という高精度のfindingsだけが返ってくる。Anthropic社内での導入前後で実質的レビューコメント付きPRの割合が16%から54%に向上したという実績がある。実行時間は10〜20分でバックグラウンド動作、Pro/Maxは3回まで無料でその後extra usage課金。Bedrock/Vertex AI/Foundry経由やZero Data Retention組織では利用不可という環境制約がある。

詳細

Claude Code v2.1.86で追加されたresearch preview機能「/ultrareview」の仕組み、料金、使い分けを解説した記事。

仕組み:

• ローカルのgit状態をリモートサンドボックスにbundle/upload（PRモードではGitHubから直接clone）
• クラウドでレビューエージェントfleetを並列起動、diffを異なる観点から探索
• 検出されたバグは独立に再現・検証され、検証を通過したfindingsのみが返ってくる（誤検知率1%未満）
• ローカルの/reviewとの違いは「検証ステップがある」こと

Anthropic社内実績:

• 実質的レビューコメント付きPR割合: 16% → 54%
• 1,000行超大型PR: 84%で指摘検出、平均7.5件
• 50行未満小型PR: 31%で指摘、平均0.5件

料金体系:

• Pro/Max: 3回まで無料（one-time allotment、更新なし）
• Team/Enterprise: 無料枠なし
• 超過後: extra usage（1回あたり$5〜$20程度との報告あり）

利用不可な環境:

• Amazon Bedrock / Google Cloud Vertex AI / Microsoft Foundry経由
• Zero Data Retention有効化組織
• APIキーのみ認証（/loginでClaude.aiアカウント認証が必要）

推奨ユースケース（公式明記）: 認証・認可変更、データマイグレーション、並行処理リファクタ、長期feature branchのマージ前最終チェック

関連機能比較:

• Code Review（Team/Enterprise向けPR自動レビュー）と/ultrareview（オンデマンドCLIコマンド）は別物

Claude Code の許可プロンプトを AI に自動削減させる「/fewer-permission-prompts」 完全解説

• URL: https://zenn.dev/akasara/articles/dac2e93c27557f
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude Code v2.1.111で追加された「/fewer-permission-prompts」スキルは、過去のセッション履歴を自動スキャンして頻繁に承認プロンプトを誘発しているread-onlyのBash/MCPコマンドを抽出し、.claude/settings.jsonへ追加するallowlist案を提案する。承認プロンプトの93%が結局approveされているというAnthropicの計測値が示す「承認疲れ」を、全スキップの–dangerously-skip-permissionsを使わずに解消する第三の選択肢として設計された。書き込み系・破壊的コマンドは提案されない設計でセーフティが保たれ、Auto ModeがないPro/APIキー利用者にとって実質的な代替手段となる。glob付き読み取り専用コマンドの自動許可（v2.1.111で同時導入）と組み合わせた三段構えのプロンプト削減パッケージの一部だ。

詳細

Claude Code v2.1.111（2026年4月16日）で追加された/fewer-permission-promptsスキルの仕組み・使い方・他手段との比較を解説した記事。作者Boris Chernyが直接推奨した公式スキル。

内部動作（3ステップ）:

• スキャン: ~/.claude/projects// 配下のセッション履歴を走査
• 抽出: read-onlyのツールコールパターンのみ特定（rm・git push・npm publish等は提案されない）
• 提案: .claude/settings.jsonのpermissions.allowに追加する優先順位付きリストを生成

v2.1.111の「プロンプト削減パッケージ」3点セット:

• glob付き読み取り専用コマンドの自動許可（ls *.ts等）
• cd &&誘発ミスを防ぐClaude自身の内部指示強化
• /fewer-permission-prompts で残った頻出コマンドを一括allowlist化

ルール構文例:

• Bash(npm run:*) → npm run + 任意引数を許可
• Bash(git *) → git単体 + git <任意>を許可
• mcp__github__list_prs → MCP ツールコール許可（括弧なし）
• 優先順位: deny > allow > ask > defaultMode

使い方:

• Claude Code内で/fewer-permission-promptsを実行するだけ（v2.1.111以上が必要）
• 過去のセッション履歴が必要で、新規セッション直後は効果なし
• 承認するとsettings.jsonが自動更新される

他手段との比較:

• 手動settings.json編集: 削減量大だが手間大
• Auto Mode: 削減量最大だがMax/Team/Enterprise限定
• Sandboxing: 安全性最高（内部テスト84%減）だが設定が複雑
• –dangerously-skip-permissions: 100%スキップだが安全性最低

注意点: スキル数が多いと認識されない場合あり（SLASH_COMMAND_TOOL_CHAR_BUDGET=30000で緩和可能）

Claude Code に Auto Mode が登場 ── 「全承認」でも「毎回承認」でもない第三の道

• URL: https://zenn.dev/akasara/articles/e7b047f018e791
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 2026年3月24日に発表されたClaude CodeのAuto Modeは、全承認の「–dangerously-skip-permissions」と毎回承認のデフォルトモードの中間に位置する第三の選択肢だ。ツール呼び出しのたびに独立したSonnet 4.6クラシファイアがリスクを評価し、低リスクは自動実行・高リスクはブロックする仕組みで、クラシファイア入力からClaude自身の生成テキストが除外されるためプロンプトインジェクション対策にもなっている。デフォルトの信頼境界は現在の gitリポジトリのみで、社内APIや組織リポジトリへの操作はsettings.jsonのautoModeブロックで宣言することでfalse positiveを解消できる。2026年6月時点ではMax・Team・Enterprise・APIプランが対象で、ProやBedrock/Vertex経由では利用不可だ。

詳細

Claude Code Auto Modeの詳細解説（2026年3月24日発表、6月時点最新情報で全面更新）。承認プロンプトの93%がapproveされるという非効率と–dangerously-skip-permissionsの危険性という二択を解消する第三の道。

クラシファイアの仕組み:

• セッションモデルとは独立したSonnet 4.6クラシファイアが各ツール呼び出しのリスクを判定
• クラシファイア入力からClaude自身の生成テキスト・ツール実行結果を除外（プロンプトインジェクション対策の核心）
• 判定3観点: スコープ逸脱・信頼できないインフラへのアクセス・プロンプトインジェクション誘導

ブロック対象（20個以上のルール）:

• Destroy/Exfiltrate: 履歴force-push・クラウドストレージ大量削除・内部データ外部送信
• Degrade security posture: ログ無効化・SSH鍵や cronによる永続化・エージェント自身の権限変更
• Safety-check bypass: 検証スキップフラグ付きの再デプロイ

autoMode設定ブロック（settings.json、4月以降整備）:

• environment: 信頼するインフラを自然言語で宣言（false positiveの大半はここで解消）
• allow: 組み込みブロックルールの例外を明示
• soft_deny: カスタムブロックルール追加
• hard_deny（v2.1.136+）: allowの例外もユーザーオーバーライドも無視する無条件ブロック
• $defaultsセンチネルを落とすと組み込み標準ルールが消える点に注意

権限モード一覧（最新）: default→acceptEdits→plan→auto→dontAsk→bypassPermissions

対応プラン（2026年6月）: Max・Team・Enterprise・API（Pro/Bedrock/Vertex/Foundryは非対応） Team・Enterpriseは管理者が先にClaude Code admin settingsで有効化必要

関連機能: /effortスライダ（low/medium/high/xhigh/max）、Dynamic workflows（Opus 4.8でEnterprise/Team/API向けに数百の並列サブエージェントを走らせる機能）

Claude Opus 4.6がリリース — 100万トークン・Agent Teams・PowerPoint統合など新機能まとめ

• URL: https://zenn.dev/akasara/articles/e81a2b495f4bbe
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 2026年2月5日リリースのClaude Opus 4.6について、100万トークンコンテキスト（Opusクラス初）・Agent Teams・PowerPoint統合・Adaptive Thinking・Context Compactionの5つの主要機能とベンチマーク結果を整理した記事。ARC AGI 2では37.6%から68.8%へと大幅改善し業界トップとなった一方、SWE-bench VerifiedはOpus 4.5の80.9%から80.8%へわずかに低下。フロンティアレッドチームがリリース前テストでオープンソースコード内に500件超の未知のゼロデイ脆弱性を発見したことも注目点。価格はOpus 4.5から据え置き（入力$5/出力$25）。

詳細

• モデル概要: claude-opus-4-6、2026年2月5日リリース、コンテキスト100万トークン（ベータ）、最大出力128,000トークン、20万トークン超はプレミアム価格（入力$10/出力$37.50）
• 100万トークンコンテキスト: MRCR v2（needle-in-a-haystack）で76%、Sonnet 4.5の18.5%と比較して圧倒的
• Agent Teams（リサーチプレビュー）: フロントエンド/API/マイグレーション担当等に作業分割して並列自律連携。API利用者・サブスクリプションユーザー向け
• Claude in PowerPoint（リサーチプレビュー）: 既存スライドのレイアウト・フォント・テンプレートを読み取りデザインガイドに沿った生成・編集。Max/Team/Enterpriseプランのみ
• Adaptive Thinking: コンテキストの手がかりから思考深度を自律判断。API effortパラメータでlow/medium/high/maxの4段階を明示指定可能
• Context Compaction（ベータ）: 長時間API対話で古い会話を要約してコンテキスト確保
• US Data Residency: 米国内限定ワークロード実行オプション、10%料金上乗せ
• ベンチマーク結果:
  • ARC AGI 2: Opus 4.6が68.8%（4.5の37.6%から大幅改善）、GPT-5.2は54.2%
  • BrowseComp: Opus 4.6が84.0%（4.5の67.8%から向上）
  • SWE-bench Verified: Opus 4.6が80.8%（4.5の80.9%からわずかに後退）
  • Terminal-Bench 2.0: Opus 4.6が65.4%で業界トップ
  • MCP Atlas（ツール使用）: Opus 4.6が59.5%（4.5の62.3%から若干後退）
• ゼロデイ発見: GhostScript・OpenSC・CGIFで500件超の未知の脆弱性をリリース前に発見・報告
• 市場影響: Claude Coworkプラグインにより法務・金融分析ソフトウェア株が急落。Anthropicは30万社超の有料法人顧客を持ちエンタープライズが事業の約80%

エンジニア達の「完全に理解した」Talk #72 イベントレポート

• URL: https://zenn.dev/easy_easy/articles/0fdf97302ffa2b
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 第72回イベントレポートで、2025年12月開催。Gradleのビルドスクリプトは内部的にDSL経由でAPIを呼び出しており、初期化・構成・実行の3フェーズのうち構成フェーズでタスクグラフを構築するという仕組みが解説され、TaskProviderなどのConfiguration Avoidance APIで遅延評価することがパフォーマンス上重要とされた。セキュリティニュース振り返りではトレンドマイクロ集計501件のうち不正アクセス・ランサムウェアが上位で、侵入経路の約8割がVPN等のネットワーク脆弱性を経由しており、サプライチェーン攻撃の増加とMFA徹底の有効性、侵入を前提としたレジリエンス強化が強調された。非同期処理については「CPU（スレッド）をブロックせず遊ばせない」という本質が整理され、API通信やDB操作など明確な待ち時間が発生する処理に限定して非同期化すべきという指針が示された。

詳細

LT1: Gradleビルドスクリプトの仕組み

• build.gradle.kts はDSL（ドメイン特化言語）でGradle APIを呼び出す
• 3フェーズ: 初期化（Initialization） → 構成（Configuration） → 実行（Execution）
• 構成フェーズでタスク依存関係グラフを構築するのが重要
• パフォーマンス最適化: TaskProvider / Configuration Avoidance APIで遅延評価（必要時のみインスタンス生成）
• DSL → API → ライフサイクルの視点でスクリプトを読み解くと納得感が深まる

LT2: 2025年セキュリティインシデント振り返り（トレンドマイクロ集計）

• 総件数: 501件
• 攻撃種別: 1位・不正アクセス、2位・ランサムウェア
• 主な事例: 高校生によるAI悪用の快活クラブ不正アクセス、アサヒグループ・アスクルへのランサムウェア
• Webスキミング（クレジットカード入力画面改ざん）も増加
• 侵入経路: VPN等ネットワーク脆弱性が約8割
• サプライチェーン攻撃（子会社・提携企業を踏み台）が目立つ
• 対策: MFA徹底 + 侵入前提のレジリエンス構築
• アスクル社の被害報告書は感染経路から再発防止策まで詳細開示で参考文献として推奨

LT3: 非同期処理の本質（入門向け）

• 並行処理（Concurrency）と並列処理（Parallelism）の区別を整理
• 同期処理: 待ち時間でスレッドをブロックしてしまう
• 非同期処理の本質: スレッドをブロックせず、CPUを有効活用すること
• 適切なユースケース: API通信・DB操作など明確な待ち時間が発生する処理（重い計算処理ではない）

エンジニア達の「完全に理解した」Talk #74 イベントレポート

• URL: https://zenn.dev/easy_easy/articles/137eb74f6f5996
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 第74回イベントレポートで、2026年2月開催。Google開発のTCP BBRはパケットロス発生まで送り続ける従来のロスベース輻輳制御（CUBIC等）に代わり、BDP（帯域幅×遅延の積）を維持しながらキューイング遅延を発生させないよう4モードで探索・推定するアルゴリズムとして解説された。PostgreSQLでは外部参照キーにデフォルトでインデックスが張られないという落とし穴が報告され、MySQLとの設計差異として親テーブルのDELETE/UPDATE時の整合性チェックで子テーブルのシーケンシャルスキャンが発生する問題が具体的に示された。Google Gemma 2ベースのTranslateGemmaは55言語対応・ローカル動作が強みだが英語への変換しかサポートしないという制限と固有名詞翻訳の弱さが検証で確認された。uLoopMCP（現Unity CLI Loop）を用いたAI駆動Unity開発では、Claude Code Plan Modeで仕様策定後に18スクリプトと全シーンを自律的に構築させた事例が報告された。

詳細

LT1: TCP BBR輻輳制御アルゴリズム（Google開発）

• 従来のロスベース制御（CUBIC等）の問題: パケットロス発生までデータを送り続け、バッファブロート（キューイング遅延）が発生
• BBRの目標: バッファを空にして遅延最小 + 送信レートをボトルネックリンク帯域幅に保つ
• BDP（Bandwidth-Delay Product）: 帯域幅と遅延の積をネットワーク中のデータ量の目標値として使用
• ジレンマ: 帯域幅と遅延を同時に正確に測定できない（帯域幅計測のために送信量を増やすと遅延が発生）
• 4モード: STARTUP / DRAIN / PROBE_BW / PROBE_RTT を行き来してネットワーク状況を探索・推定

LT2: PostgreSQLの外部参照キーとインデックスの罠

• MySQL: 外部キー制約作成時にインデックスを自動生成
• PostgreSQL: 外部参照キーにデフォルトでインデックスは作成されない
• 問題: 親テーブルのDELETE / UPDATEで参照整合性チェック時に子テーブルをシーケンシャルスキャン → データ量増加時にパフォーマンス劣化
• 推奨: 基本的に外部参照キーにはインデックスを張る
• 例外: データ量が少ない、検索されない、更新頻度が高い場合は個別検討

LT3: TranslateGemma（Gemma 2ベースの翻訳特化LLM）の検証

• 強み: 55言語対応（サポテク語などマイナー言語を含む）、ローカル動作、データが外部に出ない
• 制限: 基本的に英語への変換のみ対応（日本語に直接変換不可、英語を中継する必要あり）
• 検証結果: 英日間の一般翻訳は問題ないが、固有名詞翻訳に弱い（例：「虎の穴」→「虎の姉」）、マイナー言語の精度はまだ低い
• 評価: 単純翻訳用途ではChatGPT等に劣る

LT4: uLoopMCP × Claude Code によるUnityゲーム開発

• Unity EditorをMCP経由でAIに直接操作させるuLoopMCPを使用
• 作業範囲の自動化: コンパイル、エラー検出、ヒエラルキー把握、スクリーンショット撮影、テスト実行
• 実績: ブロック崩しゲームのプランニング〜実装まで、18スクリプトと全シーンを自律構築
• 2D版完成後に3D版へ移行もスムーズに完了
• 人間の役割: プロンプト指示出し、バグ修正・バランス調整・方向性決定に集中

エンジニア達の「完全に理解した」Talk #75 イベントレポート

• URL: https://zenn.dev/easy_easy/articles/183946c047f71a
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 第75回イベントレポートで、2026年3月開催。Android-DevPortalはデバッグ用Activityを本番バイナリに混入させずに別ランチャーアイコンとして起動できるOSS実装で、AndroidManifestのtaskAffinityとHiltの@IntoSetによる完全モジュール化でdebugImplementation追記だけで着脱可能になっている。ライブ配信技術については、HLS/DASHが大規模配信に強くWebRTCが低遅延に強いという二項対立をMedia over QUIC（MoQ）が解消しようとしており、QUICの上にPub/Subモデルを構築してフレーム単位の配信とCDNファンアウトを両立するアーキテクチャがIETFで策定中と紹介された。MCP経由の障害対応自動化の続編では、メトリクス（CPU使用率・メモリ・ネットワーク）まで自律調査できるように拡張されたが、完全自動化（自動運転レベル4相当）の本番適用は責任の所在問題から慎重な立場が示された。

詳細

LT1: Android-DevPortal（OSSデバッグポータル）

• 課題: デバッグ画面の実装コスト・ビルド時間への影響・本番への誤混入リスク
• 解決策: AndroidManifest.xmlで action.MAIN + category.LAUNCHER + taskAffinity を設定し、別ランチャーアイコンから起動可能なデバッグ専用Activity
• モジュール化: Google Navigation 3 + Hilt @IntoSet でルーティングを完全モジュール化
• 着脱: debugImplementation で追記するだけで追加、削除も記述を消すだけで完全除去
• OSSとして公開: Android-DevPortal

LT2: ライブ配信技術の変遷とMedia over QUIC（MoQ）

• 既存技術の限界:
  • HLS / DASH: 大規模配信に強いが遅延が大きい（数十秒〜分単位）
  • WebRTC: 低遅延（数百ms）だが大規模ファンアウトに弱い
• Media over QUIC（MoQ）: IETFで策定中（ドラフト段階）、両者の課題を解消する次世代プロトコル
• 仕組み: QUICの上にPub/Subモデルを構築 → 視聴者がSUBSCRIBEするとフレーム単位でデータが流れる
• スケーラビリティ: 中継サーバー（Relay）をCDN（Cloudflare等）インフラに乗せて大規模ファンアウトが可能

LT3: AI障害対応自動化の続編（技術書典新刊より）

• 拡張点: ログ分析に加え、メトリクス（CPU使用率・メモリ・ネットワーク帯域）もAIが自律調査
• AIがサーバーに自らアクセスしてクエリを書き、ダッシュボードを生成して情報提供
• 完全自動化（レベル4）は技術的に視野に入ってきたが、本番無人適用は「やらかした時の責任の所在」問題が残る
• 重要な気付き: AI向けのログ・構成図・対応履歴整備は「新人のオンボーディング環境整備」と同義

エンジニア達の「完全に理解した」Talk #70 イベントレポート

• URL: https://zenn.dev/easy_easy/articles/252d4d1a412ce4
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 第70回イベントレポートで、2025年10月開催。GitHub ActionsからGoogle Cloud（Cloud Run）への認証にWorkload Identity Federation（WIF）を使い、OIDCトークンを活用して秘密鍵なしの一時的な認証が可能になる手順が解説された。従来のサービスアカウントキー（JSON）方式が抱える漏洩リスクを根本的に解消できる点が強調されている。Goの標準ライブラリregexpがRE2ベースで先読み（lookahead）を意図的にサポートしていない理由についても、ReDoS攻撃を防ぐために最悪計算量を線形に保つという設計思想から詳細に解説されており、予測可能なパフォーマンスを機能より優先するというRE2の哲学が明示された。

詳細

LT1: GitHub Actions → Google Cloud デプロイの認証改善

• 従来方式: サービスアカウントキー（JSON）をリポジトリに保存 → 漏洩リスク高
• WIF（Workload Identity Federation）: GitHub ActionsのOIDCトークンをGoogle Cloud側で検証し、一時的な認証トークンを発行
• 設定手順: Workload Identity Pool / Provider 作成 → サービスアカウントへのインパーソネート許可 → google-github-actions/auth を呼び出す
• リポジトリ・ブランチ単位での細かい権限制御が可能

LT2: LTのコツと継続の心構え（74週連続登壇の経験より）

• 目的を1つだけ決める、欲張らない
• スライドより先に台本で流れを確認する
• 「DDD（Deadline Driven Development）」: 登録してから内容を考える
• チェスプロが5秒と30分で打つ手が86%一致するという研究を引き合いに、最初の直感を信じる

LT3: GoのregexpとRE2の設計思想

• Go標準regexp: GoogleのRE2アルゴリズム準拠、先読み・後読みを意図的に非サポート
• 先読みアルゴリズムの計算量: a?のようなオプション要素がN個あると最悪2^N通りの分解 → 指数爆発
• RE2の最優先設計方針: 入力長に対して線形時間で動作すること
• ReDoS（正規表現DoS）攻撃をアーキテクチャレベルで防止するため、機能より予測可能なパフォーマンスを選択

エンジニア達の「完全に理解した」Talk #71 イベントレポート

• URL: https://zenn.dev/easy_easy/articles/87042b3ecb2517
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 第71回イベントレポートで、2025年11月開催。MCPサーバーを活用してLLMに自律的な検索クエリ生成と情報収集をさせることで深夜の障害対応を効率化する取り組みが紹介され、情報が分散する緊急時に新人でも対応しやすくなるという実用的な事例として共有された。AI駆動開発の文脈では、IDEへのAI常駐とMCPの組み合わせによりAIがローカルファイルやDBに直接アクセスする開発スタイルが解説され、AWSのAI-DLC（AI-Driven Development Life Cycle）フレームワークが紹介された。AndroidのアクティビティライフサイクルについてはAIが生成したコードが「アクティビティを保持しない」開発者オプション下でカウントリセットが起きるという実演を通じ、onSaveInstanceStateやDataStoreへの状態保存の必要性が具体的に示された。

詳細

LT1: MCPサーバーによる障害対応自動化

• 課題: 深夜アラート時の複数ツール横断「検索疲れ」
• 解決: MCP（Model Context Protocol）サーバーでLLMと外部ツールを接続し、AIが自律的に検索クエリを生成して情報収集
• 効果: 情報分散が激しい緊急時の対応効率化、新人でもオンコール参加しやすくなる

LT2: AI駆動開発の原理と構造

• AIの強み: 要件から構造を理解し、全体的な整合性を保ちながらコード・ドキュメントを生成・編集
• 人間の役割: 問題設定・最終判断などの上流工程に集中
• アーキテクチャ: IDE常駐AI + MCP → AIがローカルファイル・DBに直接アクセス
• AWS AI-DLC（AI-Driven Development Life Cycle）フレームワークを適用で開発速度・品質が向上
• 展望: 少人数で大規模プロダクトを開発できる「1人ユニコーン」時代

LT3: AndroidアクティビティライフサイクルとAI生成コードの落とし穴

• 問題: AIが生成した一見正しいコードが、開発者オプション「アクティビティを保持しない」設定下でカウントリセット
• 対策: onSaveInstanceStateで状態の保存・復元処理を実装
• さらに深い問題: 「バックグラウンドプロセスを使用しない」設定でプロセスが停止し、シングルトンで保持していたログイン状態まで初期化
• 根本的解決: SharedPreferences / DataStore などのストレージに状態を保存する設計への見直し
• 開発者オプションを使った適切なテストが重要

【週末2日】Claude Codeでコミュニティポータルサイトを構築・リリースするまでの全記録

• URL: https://zenn.dev/easy_easy/articles/89318e4d0acb4f
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 週末2日間でClaude Codeを使い、エンジニアコミュニティのポータルサイト（Next.jsではなくPython + Jinja2 + GitHub Pages構成）を構築してリリースした開発記録。コードの実装だけでなく仕様書整備・Skill作成・Issue起票・PR作成・セキュリティ監査・README作成・リリースノート整備まで開発に関わるほぼ全作業をClaude Codeで完結した点が特徴的だった。CLAUDE.mdをエントリポイントとして最小限に保ち、詳細はSkill・Rules・ステアリングドキュメントに委譲する4層構造でコンテキスト共有を設計し、Speaker DeckのoEmbed API・Google Slides・Docswell等の埋め込みURL自動生成ロジックやspeakers.yaml一元管理による全ページへの即時反映など、決定論的なビルドスクリプト設計が具体的に示されている。

詳細

技術スタック選定

• 動的機能・ログイン・書き込み不要の静的サイト
• データ管理: YAML（イベントごとにファイル分割）
• ビルド: Python + Jinja2
• ホスティング: GitHub Pages
• CI/CD: GitHub Actions（push → 自動ビルド＆デプロイ）

CLAUDE.mdの設計方針

• エントリポイントとして最小限（プロジェクト概要・コマンド・ドキュメントの所在のみ）
• 詳細は .claude/rules/（開発ルール・登壇者管理ルール）に委譲
• 4層コンテキスト共有: CLAUDE.md / Skill / Rules / .steering/

スライド埋め込みURL自動生成

• Google Slides: URLパターンマッチでembedURL構築
• Docswell: パスから日付サフィックスを除去してslug取得
• Speaker Deck: oEmbed API呼び出し（結果はキャッシュ）
• slides.com, SlideShare: それぞれURL変換ルール

登壇者管理設計

• data/speakers.yaml で一元管理
• 各イベントYAMLには speaker.id と speaker.name のみ記載（プロフィール情報は書かない）
• ビルド時にspeakers.yamlとマージ → 全イベントページに即時反映
• アイコン優先度: icon_url（直接指定）→ GitHubアバター（フォールバック）

Claude Codeで完結した作業範囲

• 仕様ドキュメント整備（docs/specs/ に8ファイル）
• Skill・Rules作成（/update-specs スキル）
• 技術選定の相談・Issue起票・PR作成
• サービス命名・README英日作成・バッジ追加
• セキュリティ監査・ブランチ保護（GitHub Ruleset設定）
• Git履歴の機密データ完全削除・リリースノート整備

エンジニア達の「完全に理解した」Talk #73 イベントレポート

• URL: https://zenn.dev/easy_easy/articles/8a92c47f0b3d51
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 第73回イベントレポートで、2026年1月開催。SMTPはデフォルトで認証機能を持たないためなりすましが可能という構造的課題があり、ESMTPとSMTP-AUTHによる認証拡張の仕組みがターミナルからのライブデモを交えて解説された。Web Serial APIについては、ブラウザからハードウェアとシリアル通信できる仕組みとしてChromiumが対応する一方FirefoxとSafariがセキュリティ上の理由からあえて非対応にしているという設計思想の違いが紹介され、APIの二重ループ構造をRxJSでラップした自作npmパッケージ @gurezo/web-serial-rxjs の公開も報告された。Raspberry Pi Zeroにブラウザからシリアル通信してLinuxコマンドを実行するライブデモも実施された。

詳細

LT1: SMTPとESMTPの認証構造

• SMTP（Simple Mail Transfer Protocol）: インターネット黎明期からのプロトコル、デフォルトで認証機能なし → なりすまし送信が可能
• ESMTP（Extended SMTP）: 拡張版、SMTP-AUTHで送信元の正当性を検証できるように
• ライブデモ: ターミナルからGmailのSMTPサーバーに接続し、Base64エンコードした認証情報をAUTH LOGINコマンドで送信
• 背景: 業務でGoからSendGridに接続する処理を読んだことがきっかけ

LT2: Web Serial APIとRxJSラッパーの自作

• Web Serial API: ブラウザから直接ハードウェアとシリアル通信できる
• ブラウザ対応状況の思想差異:
  • Chrome（Chromium系）: 利便性重視で対応
  • Firefox / Safari: ハッキング・悪用のセキュリティ懸念からあえて非対応
• APIの構造的課題: 読み書きそれぞれにwhileループを持つ二重ループ構造で実装が複雑
• 解決策: RxJSでAPIをラップし、Observableベースで簡潔に記述できるnpmパッケージ @gurezo/web-serial-rxjs を自作・公開
• ライブデモ: Raspberry Pi Zeroにブラウザからシリアル通信し、Linuxコマンドを実行して応答を受信

エンジニア達の「完全に理解した」Talk #76 イベントレポート

• URL: https://zenn.dev/easy_easy/articles/ac26a2edcc7729
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 第76回イベントレポートで、2026年4月開催。npmパッケージ公開においてSemVer・Conventional Commits・TypeDoc・npm Trusted Publishing（OIDC）・npm pack --dry-runによる事前検証という一連の自動化フロー整備が実践例として共有された。AI活用による業務効率化事例としては、Geminiの専属アシスタント「エンジェル」に社内規程と上司のレイアウトの癖を学習させることでチェックバックをほぼゼロにした非エンジニア職の実践が紹介された。Google Cloud上でQwen3.5等のLLMを自前運営しようとしたところ、terraform applyの成功がインスタンス即時停止を保証しないという落とし穴と、Google CloudにハードなコストリミットがないことでGPUインスタンスが1日約3.6万円（月50〜60万円）稼働し続けた事例が「教訓」として詳細に語られ、最終的にオンプレミス（GMKtec EVO-X2 + Tailscale）への転換が報告された。

詳細

LT1: npmパッケージ公開の自動化フロー整備

• バージョン管理: SemVer（MAJOR.MINOR.PATCH）
• コミット規約: Conventional Commits を @commitlint/cli + husky で強制
• ドキュメント: TypeDoc + typedoc-rhineai-theme で自動生成 → GitHub Pages へデプロイ
• CI: GitHub Actions で ci.yml / commitlint.yml / deploy-docs.yml / release.yml を分割管理
• 認証: npm Trusted Publishing（OIDC）で認証情報なしに公開
• 事前検証: npm pack --dry-run で同梱物を確認してから公開
• 公開後確認: npmx.dev などで確認
• 題材: @gurezo/web-serial-rxjs

LT2: Geminiで業務の「マウント」問題を解消（非エンジニア職の事例）

• 課題: 組織ルールを盾に取る総務担当者・レイアウトばかり指摘する上司との不毛なやり取り
• 解決策: Geminiの「Gem」機能で専属AI「エンジェル」を育成
  1. 社内の総務規程・出張・経費精算ルールを学習させる
  2. 担当者の言い回し・上司の過去PDF資料のレイアウト癖（余白・フォント・言い回し）を把握させる
  3. カテゴリートリガーで一覧表示できるインターフェースを整備し社内共有
• 成果: チェックバックがほぼゼロになり、創造的業務に時間を使えるように

LT3: Google Cloud + Terraform のコスト爆発と教訓（100週連続登壇）

• 目的: クラウドAI API課金対策として自前AIサーバーをGoogle Cloud上に構築
• モデル: Qwen3.5 9B（軽量）・Qwen3.5 35B-A3B（MoE中規模）・GLM-4.7 flash（コーディング向け）
• 計画: 平日8〜22時稼働・土日停止で月数万円に抑える予定
• 落とし穴1: terraform applyでスケーリング上限を0に書き換えて成功しても、起動中のGPUインスタンスには即時反映されず夜間・土日も稼働し続けた
• 落とし穴2: Google Cloudは予算アラートはあるが「金額超で強制停止」のハードリミットがない（Cloud Functionsで自作可能だが実際には設定していなかった）
• 結果: 1日約3.6万円消費、月間請求が約50〜60万円に到達。Googleサポートに救済を求めたが今回は救済なし
• 教訓: terraform applyの成功は期待通りの動作を保証しない / 「アラートはあるがリミットはない」
• 最終結論: GMKtec EVO-X2（Ryzen AI Max+ 395 / メモリ128GB）にUbuntu + Qwen3.5系モデルを入れてオンプレAIサーバー化、Tailscale + WebUIで運用

エンジニア達の「完全に理解した」Talk #77 イベントレポート

• URL: https://zenn.dev/easy_easy/articles/d534178cb3d59b
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: エンジニアコミュニティ「Easy Easy」の月次LTイベント第77回の記録で、2026年5月開催。リファクタリングを「調査・整地・剪定・再編・検証・収束」の6フェーズに分解し、前工程（調査〜剪定）での設計判断が成否を左右するというフレームワークが提示された。AI時代でもコンテキストウィンドウの限界や暗黙知の非観測性から、前工程は人間が担うべきだという指摘は具体的で説得力がある。SaaSの権限管理については「何ができるか」をPBAC（ポリシーベースアクセスコントロール）で管理し、「誰のリソースか」をReBAC（リレーションベースアクセスコントロール）で管理する2層設計が紹介され、無効なリソースへのアクセスに404を返してリソース存在を隠蔽するという実践的なポイントも共有された。

詳細

LT1: リファクタリングのフェーズフレームワーク

• 6フェーズ: 調査・整地・剪定・再編・検証・収束
• 前3フェーズ（調査〜剪定）の完成度が成否を決定する
• AI補助の限界: コンテキストウィンドウ超過時に全体像を維持できない、暗黙知・文化的文脈は観測不可
• 役割分担: 前工程（設計・判断）は人間、実行フェーズ（命名改善・モジュール分割）はAIが担う
• 変更単位を細かくする「細分化デプロイ」でリスクを分散

LT2: マルチテナントSaaSの権限管理設計

• やらかしパターン: ロール条件分岐をコードに直書き、権限用テーブルの増殖
• PBAC（ポリシーベースアクセスコントロール）: 「何ができるか」をポリシークラスに集約し、ロール×プランの組み合わせで評価
• ReBAC（リレーションベースアクセスコントロール）: 「誰のリソースか」でテナント間横断アクセスを防止
• セキュリティ実践: 権限のないリソースへのアクセスに403ではなく404を返してリソース存在を隠蔽
• 2層分離により機能追加・仕様変更に強い権限管理が実現

AI関係の開発者向けディスク容量削減方法

• URL: https://zenn.dev/karaage0703/articles/06bc15bbc190db
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: AI 関連開発を行う Mac/Linux ユーザー向けに、ディスク容量を大幅に削減するための手順をまとめた実用的なリファレンス記事。Hugging Face モデルキャッシュ（~/.cache/huggingface）、Docker イメージとビルドキャッシュ（docker system prune -a –volumes）、Ollama モデル（ollama rm）、uv キャッシュ（uv cache clean）、Chrome キャッシュ、snap 古いリビジョンなど対象ごとに確認コマンドと削除コマンドを示している。Claude Code などのコーディングエージェントにこの記事の URL とプロンプトを渡すだけで自動的に対応できると案内している。

詳細

削除対象と手順:

Hugging Face キャッシュ:

• 確認: du -sh ~/.cache/huggingface/hub/*
• 削除: rm -rf ~/.cache/huggingface/hub/（使用時に再ダウンロードされる）

Docker:

• 確認: docker system df（未使用イメージ・ビルドキャッシュが数十GB になることも）
• 削除: docker system prune -a –volumes（全削除）または docker builder prune -a（ビルドキャッシュのみ）

Ollama モデル:

• 確認: ollama list（モデルごとのサイズと更新日時）
• 削除: ollama rm モデル名（例: ollama rm llama2:latest）

uv キャッシュ: uv cache clean（1コマンドで完了）

Chrome キャッシュ:

• macOS: rm -rf ~/Library/Caches/Google/Chrome
• Linux: rm -rf ~/.cache/google-chrome
• 複数プロファイルの場合は各プロファイルごとに分かれている点に注意

Linux snap 古いリビジョン:

• sudo snap list –all でリビジョン確認し、disabled なものを sudo snap remove で削除

macOS/Linux 対応パスは記事内の対応表を参照 筆者実績: PC1台あたり数十〜数百GB の容量削減が可能

OpenClawライクなソフトをまとめてみた

• URL: https://zenn.dev/karaage0703/articles/0e2e3484169db2
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: OpenClaw（30万超スター）を起点に、派生・独立系のパーソナル AI アシスタントおよび CLI コーディングエージェントを「チャットアプリ型」「ターミナル型」「Web UI 型」「ブリッジ型」の4カテゴリに整理して紹介している。Rust・Go・Zig・TypeScript・Python・C など多様な言語で実装された軽量版から企業バック付きのプロジェクトまで20以上を網羅する。Claude Code や Codex を既存のチャットアプリやWeb UIから橋渡しするブリッジ型という分類も実用上の視点を提供している。

詳細

チャットアプリ型（OpenClaw 派生）:

• Hermes Agent: Nous Research 製、自己改善型、200以上のモデル対応、MITライセンス
• nanobot: 約4,000行の超軽量版、Python製
• ZeroClaw: Rust製・5MB未満・WASMサンドボックス
• PicoClaw: Go製・$10ハードウェアで動作・RAM 10MB未満
• NanoClaw: TypeScript製・Anthropic Agents SDK上で動作
• NemoClaw: NVIDIA GTC 2026 発表、OpenShell でサンドボックス化
• IronClaw: Rust製・NearAI 開発
• NullClaw: Zig製・678KB・起動2ms未満
• zclaw: C言語製・ESP32 向け・888KiB

ターミナル型:

• OpenCode: 75以上の LLM プロバイダー対応
• Cline: VS Code 内自律エージェント・Apache 2.0
• Aider: git-first Python製・410万インストール以上
• Goose: Block社（旧Square）開発・Rust製
• Siki: Go製・完全ローカル・sh3z 開発

ブリッジ型（CLIをリモート操作する中間層）:

• claudecodeui: Claude Code/Cursor CLI/Codex をモバイル・Web から操作
• xangi: Discord/Slack 経由で Claude Code/Codex/Gemini CLI を統合操作（筆者開発）
• GeminiClaw: Gemini CLI ブリッジ・TypeScript製・多層キャッシュ
• mugi-claw: Slack 常駐・macOS sandbox-exec・Playwright 連携

Web UI 型: OpenHands（旧 OpenDevin）、openwork（OpenCode ベース）

DGX Spark のファームウェアアップデートをしてみた

• URL: https://zenn.dev/karaage0703/articles/0eb4f945918e54
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: NVIDIA DGX Spark（GB10）の本体ファームウェアをLVFS経由でfwupdmgrコマンドを使ってアップデートした実機レポートだ。Embedded Controller・SoC FW（UEFI/GPU）・USB-C PD Controllerの3コンポーネントが対象で、3〜4世代古い状態からfwupdmgr upgrade一発で最新版へジャンプアップできることを確認した。作業時間は約30分。LLM推論速度の向上についてはQwen3.6-35B-A3Bで+2.0%、Qwen3.5-9Bで+0.46%にとどまり、フォーラムで報告されていた+6%には届かなかった。

詳細

対象コンポーネントとバージョン（実機）

• Embedded Controller: 0x02004203 → 0x03000302（519 kB）
• SoC FW（UEFI/GPU）: 0x02008433 → 0x0200980f（30.4 MB）
• USB-C PD Controller: 0x00000500 → 0x00000516（1.1 MB）

手順

1. sudo apt update && sudo apt dist-upgrade && sudo fwupdmgr refresh --force（DBを最新化）
2. fwupdmgr get-devices（適用前バージョンを記録）
3. fwupdmgr get-updates（適用可能アップデートを確認）
4. sudo fwupdmgr upgrade（対話プロンプトでyを選択、自動再起動してUEFIフラッシュ）
5. fwupdmgr get-history && fwupdmgr get-devices（Success確認）

注意点

• Embedded Controllerは中間バージョンを順番に当てる必要はなく最新へ一発ジャンプ可能
• fwupdmgr get-devicesでUEFI Device Firmwareが2行表示されるが片方がSoC FW、もう片方がUSB-C PD Controller（get-updatesで配下に表示される名称で区別）

実測LLM推論速度（Ollama、seed=42、num_predict=200、3回中央値）

• qwen3.6:35b-a3b: 59.66 → 60.84 tok/s（+2.0%）
• qwen3.5:9b: 36.77 → 36.94 tok/s（+0.46%）
• フォーラム報告値の+6%には届かず

フォーラム報告（自分での未検証）

• LLM推論速度約+6%向上
• ツール呼び出し（tool use）の安定性向上
• GB10 power limited after crash系の不具合解消

VS Codeが定期的に真っ黒になる時の対処法

• URL: https://zenn.dev/karaage0703/articles/17daa7fcaa00ee
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: macOS 15.5 / MacBook Pro M4 環境で VS Code のウィンドウが定期的に真っ黒になる問題の解決策を記録した短い記事。GPU 描画ではなく Local Storage や Session Storage の破損が原因と判明し、~/Library/Application Support/Code 配下のキャッシュ関連ディレクトリを削除することで復旧できた。settings.json や拡張機能には影響せず、ハードウェアアクセラレーション無効化などの一般的な対処は効果がなかった。

詳細

• 症状: VS Code ウィンドウが真っ黒になり再起動しても直らず、定期的に再発
• 環境: MacBook Pro 14インチ (Nov 2024) / Apple M4 / 16GB / macOS 15.5
• 解決手順:
  1. pkill -f “Visual Studio Code” && pkill -f “Electron” でプロセスを完全終了
  2. cd ~/Library/Application\ Support/Code
  3. rm -rf “Local Storage” “Session Storage” “Cache” “CachedData” “Code Cache”
• 原因: GPU 描画ではなくローカルストレージ・セッション情報の破損
• 削除後、settings.json と拡張機能は保持されたまま表示が回復
• 効果がなかった対処: argv.json で “disable-hardware-acceleration”: true、GPUCache の削除

Karpathy氏の200行GPT「microGPT」を1行1行読み解く

• URL: https://zenn.dev/karaage0703/articles/1e7106add712d1
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Andrej Karpathy氏が2026年2月に公開した200行・外部ライブラリ依存なしのGPT実装「microGPT」をコードレベルで読み解いた解説記事だ。PyTorchもNumPyも使わずに自動微分エンジンから始めてTransformerの訓練・推論まで実装しており、約32,000個の英語人名データから人名らしい文字列を生成することで動作を確認できる。コードは6セクションに分かれ、スカラー値の自動微分・多ヘッドアテンション・Adam最適化の各実装が丁寧に解説されており、GPTアーキテクチャの内部動作を理解するための素材として有効だ。

詳細

microGPTの概要

• パラメータ数: 4,192（GPT-4の数千億と比べ極小）
• 学習データ: 約32,000個の英語人名
• 依存ライブラリ: なし（Python標準ライブラリのみ）
• 実行: curl -O https://gist.githubusercontent.com/karpathy/.../microgpt.py && python3 microgpt.py

6セクションの構成

• データ準備（~20行）: 人名データセット読み込みとランダムシャッフル
• トークナイザ（~5行）: 文字レベルの文字→数値ID変換、語彙サイズ27（26文字+BOS）
• Autograd（~50行）: Valueクラスにdata/grad/_children/_local_gradsを持たせ計算グラフを構築、backward()でトポロジカルソート→連鎖律で逆伝播
• パラメータ初期化（~15行）: n_embd=16, n_head=4, n_layer=1, block_size=16
• モデル定義（~60行）: GPT-2準拠。LayerNorm→RMSNorm、GeLU→ReLU、バイアスなしの3点を簡略化
• 訓練+推論（~50行）: Adam最適化（beta1/beta2の移動平均）で1000ステップ学習

マルチヘッドアテンション実装のポイント

• Q/K/V射影後に4ヘッドで並列処理
• スケーリングはhead_dim**0.5で除算（内積が大きくなりsoftmaxが極端にならないよう）
• 残差接続でアテンション前後・MLP前後を足し戻して勾配消失を防止

huskyでmainブランチへの直接pushを禁止する方法

• URL: https://zenn.dev/karaage0703/articles/5113cedc2238df
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude Code や Codex などの AI エージェントが誤って main ブランチへ直接 push してしまうリスクに対し、Node.js プロジェクトで husky の pre-push フックを使ってローカルレベルでブロックする方法を紹介している。フック自体は数行のシェルスクリプトで、push 先が refs/heads/main の場合に exit 1 を返す仕組み。–no-verify や GitHub Web UI からの操作は防げないため、チーム開発では GitHub の branch protection rules への課金が確実だと明示している。

詳細

• 背景: claude –dangerously-skip-permissions を使った自動化開発で、AI が意図せず git push origin main を実行するリスクへの対処
• 前提: Node.js プロジェクト、husky インストール済み（npm install husky –save-dev && npx husky init）
• フック: .husky/pre-push に remote_ref が refs/heads/main のときに exit 1 するシェルスクリプトを配置
• chmod +x .husky/pre-push で実行権限付与が必要
• ブランチからの push は正常に動作することを確認済み
• 抜け穴: husky 未設定環境、git push –no-verify、GitHub Web UI からの操作は防げない
• Python / 非 Node.js プロジェクトの代替: .git/hooks/pre-push に直接配置（Git 標準機能）、または pre-commit フレームワーク（筆者未検証）
• 確実な保護にはプライベートリポジトリで GitHub branch protection rules への課金が必要

ローカルワークスペースのMarkdownファイルをブラウザで閲覧・編集できる軽量Webアプリを作った

• URL: https://zenn.dev/karaage0703/articles/78056e4d3e07a2
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: ローカルのMarkdownファイルをブラウザから閲覧・編集できる軽量WebアプリworkspaceーwebーeditorをOSSとして公開した紹介記事だ。ObsidianのWikiーlink・Backlinks・Quick Switcherに相当する機能をブラウザから使えるように実装しており、Tailscale越しにスマートフォンからも編集できる点が特徴となっている。DGX Spark上でxangiなどのAIアシスタントが生成したMarkdownファイルをリアルタイムで確認・修正したいという動機から作られ、AIアシスタント向けのSKILL.mdも同梱されている。技術スタックはNode.js+Express+marked+highlight.js+Mermaid。

詳細

主な機能

• ディレクトリツリー、パンくずナビ、タグフィルター（フロントマターのtags:/category:で絞り込み）
• Markdownプレビュー（Mermaid図・シンタックスハイライト対応）
• Wiki-link [[name]] のクリック遷移、未解決リンクは点線表示
• Backlinks: 起動時にワークスペース全体をスキャンしてインメモリインデックス化、通常Markdownリンクも対象
• Quick Switcher: Cmd/Ctrl+Pでファジー検索（VSCode/Obsidian風）
• ライト/ダークテーマ切替（永続化、prefers-color-scheme追従）。Mermaidもテーマ連動
• ブラウザ内編集 + Ctrl+S保存
• ワンクリックGit sync（git pull && git add -A && git commit && git push）
• モバイル対応（ペイン切替）

技術スタック

• Node.js 18+ / Express / marked v12 / highlight.js / Mermaid 11（ESM経由）

起動

• WORKSPACE_DIR=/path/to/your/workspace PORT=9080 node src/server.js
• Tailscale越しスマホアクセス: echo "http://$(tailscale ip -4):9080"

Agent Skillとして使用

• リポジトリにSKILL.mdが同梱されており、スキルディレクトリに配置するだけで利用可能
• 筆者はAIアシスタント起動時に自動起動する設定で使用

Git syncの注意点

• git add -Aで全変更を対象にするため、不要な変更は.gitignoreで事前除外が必要

アタマだけのスタックチャン「stackchan-atama」を作った

• URL: https://zenn.dev/karaage0703/articles/7afc5144de899a
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: スタックチャン（M5Stack ベースのロボット）のアタマ部分のみを独立させた OSS「stackchan-atama」を紹介している。M5Stack CoreS3 または Core を USB 接続するだけで、PC や Raspberry Pi からテキストを送ると VOICEVOX 等の TTS 経由で口パク付きで喋らせることができる。リポジトリが Agent Skills 形式になっているため、Claude Code に自然言語でセットアップや制御を依頼できる点が特徴的で、フィジカル AI の手軽な導入例となっている。

詳細

• 対象ハードウェア: M5Stack CoreS3（推奨・PSRAM 512KB・カメラあり）または Core（PSRAM なし・WAV 上限 80KB）
• ファームウェア書き込みは PlatformIO CLI（uv tool install platformio）で実施
• 制御は Python 製 CLI ツール（stackchan_atama.py）から USB シリアルまたは WiFi HTTP 経由
• TTS エンジン: VOICEVOX（Mac/Linux）または piper-plus（Raspberry Pi 等）に対応
• パイプライン再生対応: 長文を句読点で分割して順次送信し、最初チャンク再生中に次チャンクを合成・送信することで体感待ち時間を短縮
• 表情変更: happy/sad/angry/sleepy/doubt/neutral の6種
• Agent Skills 形式: リポジトリを .claude/skills/ にクローンするだけで Claude Code がスキルとして認識し、「ファームウェアを書き込んで」「しゃべらせて」と自然言語で指示できる
• Raspberry Pi + xangi フレームワーク経由でスケジュール定期発話なども実現可能

ローカルLLM用の簡易版スキルとしてトリガーという機能を考えてみました

• URL: https://zenn.dev/karaage0703/articles/89631872ca5a86
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: ローカルLLMがAgent Skillsをうまく扱えない問題への対処として、triggersディレクトリにシェルスクリプトを置くだけでLLMにカスタムツールを追加できる「トリガー」機能を自作AIアシスタントフレームワークxangiに実装した提案記事だ。スキルとFunction Callingの中間的な位置づけで、trigger.yamlで名前・説明・実行スクリプトを定義し、LLMがユーザー入力に応じてFunction Callingでシェルスクリプトを呼び出し、stdoutをLLMに返して自然言語で応答する仕組みだ。天気予報やテックニュース取得などのシェルスクリプト実例も示されている。Qwen3.6-35B-A3Bの性能向上でスキルが直接使えるようになりつつあるとも言及しており、低性能LLMのツール活用策としての位置付けが明確だ。

詳細

トリガーの動作フロー

1. xangi起動時にワークスペースのtriggers/をスキャンしてツール定義を自動生成
2. LLMにカスタムツールとして登録（Function Calling経由）
3. ユーザー入力に応じてLLMがトリガーを呼び出す
4. handler.shが実行され、stdoutがLLMに返される
5. LLMが結果を踏まえて自然な文章で応答

ディレクトリ構成 workspace/triggers/{trigger-name}/trigger.yaml + handler.sh

trigger.yamlのフィールド

• name（必須）: ツール名（LLMがFunction Callingで呼ぶ名前）
• description（任意、具体例を含めて書くと精度向上）: ツールの説明
• handler（必須）: 実行スクリプトのファイル名

handler.shの仕様

• cwd=ワークスペースルートでbash handler.sh [引数...]実行
• 引数はLLMのFunction Callingがargsとしてスペース区切りで渡す
• stdoutがLLMへの返り値

実例

• 天気予報: curl -s "wttr.in/${1:-Tokyo}?format=3&lang=ja"
• テックニュース: RSSをcurlで取得してPython+xml.etree.ElementTreeで上位5件をパース（uv runで仮想環境不要）

スキルとの比較

• トリガー: 確実な再現性、低い柔軟性
• スキル: 高い柔軟性、高性能LLM必要
• トリガーはスキルとFunction Callingの中間的な仕組み

xangiのDocker quickstart

• git clone https://github.com/karaage0703/xangi.git && cd xangi && ./quickstart.sh
• デフォルトはGemma4:26b、localhost:18888でブラウザからアクセス可能

DGX SparkでNemoClawをローカル実行

• URL: https://zenn.dev/karaage0703/articles/8bf663501cd4bc
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: NVIDIA が GTC 2026 で発表した NemoClaw を、NVIDIA DGX Spark（aarch64 / Ubuntu 24.04）上で Ollama + Nemotron モデルだけを使ってローカル実行した手順をまとめている。NemoClaw は NemoClaw CLI・OpenShell サンドボックス・OpenClaw エージェントの3層構造で、Landlock/seccomp/netns によりプロセス・ファイル・ネットワークを隔離しながら AI エージェントを動作させる。APIキー不要・完全ローカルでの動作を確認しており、DGX Spark 固有の cgroup v2 対応手順も記録されている。

詳細

• 構成3層: NemoClaw（セットアップ CLI）、OpenShell（サンドボックスランタイム）、OpenClaw（TUI/CLI エージェント）
• 動作環境: DGX Spark / aarch64 / Ubuntu 24.04 / Docker 28.3.3 / Node.js v22.21.0 / Ollama / GPU: NVIDIA GB10
• OpenShell は aarch64 バイナリを GitHub Releases から直接取得（v0.0.6）
• NemoClaw は npm install -g でグローバルインストール（sudo env “PATH=$PATH” が必要）
• DGX Spark 固有の問題: cgroup v2 のデフォルト設定では k3s が起動しない → /etc/docker/daemon.json に “default-cgroupns-mode”: “host” を追加して Docker 再起動
• Ollama モデルは nemotron-3-nano（小）と nemotron-3-super（大）を pull
• nemoclaw onboard の対話式ウィザードで「Local Ollama (localhost:11434)」を選択するだけでゲートウェイ起動・サンドボックス作成・推論ルーティングが完了
• openclaw tui でチャット UI 起動、日本語応答を確認
• OpenShell は Claude Code や Codex など他の AI エージェントにも対応しているとのこと

Claude CodeのSkillsを使うついでにMCP・スラッシュコマンド・サブエージェントとの違いを整理してみた

• URL: https://zenn.dev/karaage0703/articles/8c1e0434152f35
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude Code の Skills・スラッシュコマンド・サブエージェント・MCP の4つを「ユースケース / 実装コスト / 自然発動か否か / トークン消費 / 想定外挙動のリスク」などの観点で比較整理した記事。Skills は自然発動かつトークン消費が小さいが共通規格化が進行中であり、MCP は外部操作の構造化に強くプロトコルとして安定している。また Skills を試す際の公式プラグイン marketplace の利用方法（/plugin marketplace add）や SKILL.md のディレクトリ構造も紹介している。

詳細

比較表のポイント:

• Skills: 判断+手順を LLM に任せる、実装コスト小、自然発動、共通規格化進行中、トークン消費小、解釈・行動とも想定外が起こりうる
• スラッシュコマンド: 定型操作の明示的実行、コスト小、明示的発動、UI 依存で非共通
• サブエージェント: 視点・役割分離、コスト小〜中、自然発動、トークン消費大（独立コンテキスト）
• MCP: 外部操作・API の構造化、コスト中〜大、LLM が判断して自然発動、プロトコルとして最も共通性が高い

追記情報:

• スラッシュコマンドは Skills に統合済み（スラッシュコマンドとして登録しても Skills のように自然発動する）

Skills のディレクトリ構造:

• skill-name/SKILL.md（YAML フロントマター + マークダウン手順、必須）
• scripts/ 実行コード、references/ 参照ドキュメント、assets/ 素材（任意）

プラグイン marketplace の追加: /plugin marketplace add anthropics/claude-code インストール後のキャッシュは ~/.claude/plugins/cache/ に格納。古いスキルが残る場合はこのキャッシュを削除して再インストール

著者の結論: LLM にツールを使わせる基本は Skills で十分。製品組み込みは MCP か Tool Use（Function Calling）を使うべき

本棚Webアプリ「BiblioCanvas」をCLI+スキルでAIから使いやすくしました

• URL: https://zenn.dev/karaage0703/articles/8daffce3c7391f
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Kindleの蔵書2600冊以上を管理するWebサービスBiblioCanvasに対して、AIエージェントから操作できるCLIツールbibliocanvas-cliとAgent Skills対応のSKILL.mdを追加した実装紹介だ。npmでグローバルインストールしてCLIから操作できるほか、SKILL.mdをAIツールのスキルディレクトリに配置するだけでClaude CodeなどがBiblioCanvasのCLIを理解して自律的に本棚を操作できるようになる。シリーズ全巻のAmazonからのASIN取得・一括登録、読了ステータス更新とメモ追加などをDiscordからの自然言語指示だけで処理できることを示している。また本体側にも「===」区切りのひとこと感想+読書ログの二段構成で読書ブログ的に公開できる機能を追加した。

詳細

bibliocanvas-cliのセットアップ

• npm install -g bibliocanvas
• 初回: bibliocanvas login（Google認証）

AIエージェント向けスキル設定（Claude Codeの例）

• git clone https://github.com/karaage0703/bibliocanvas
• ln -s /path/to/bibliocanvas/skills/bibliocanvas .claude/skills/bibliocanvas

AIでの操作例

• 「イクサガミ全巻を本棚に追加して」→ AmazonからASIN取得して全巻登録
• 「この本読了にして、感想も書いて」→ ステータス更新+メモ追加
• 「xxxxの音声配信で紹介した本を本棚に追加して」→ 該当本を検索して登録
• SKILL.mdにAmazon表紙画像取得方法やシリーズ全巻一括登録手順も記載済み

読書ログ機能（BiblioCanvas本体への追加）

• メモに===を入れると前半がひとこと感想、後半が読書ログ（長文）として区分
• 公開本棚で「本棚モード」と「読書ログモード」を切り替え可能

設計上の知見

• 個人用Webサービスへの最も手軽なAI対応策はCLI化+SKILL.mdの添付
• 本格的な複数エージェント対応が必要になればMCPサーバー化を検討する段階

Qwen3-TTSで10秒の音声で自分の声をクローン

• URL: https://zenn.dev/karaage0703/articles/97f8a01cbb9c49
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Alibaba Cloud が開発した Qwen3-TTS（1.7B パラメータ、Apache 2.0）を使い、10秒程度のポッドキャスト音声サンプルから自分の声をクローンした実験記録。NVIDIA DGX Spark（Grace CPU / GB10 GPU / 128GB 統合メモリ、Ubuntu 24.04 aarch64）上で CUDA 13.0 / Python 3.12 / uv 環境で動作させた手順を詳しく記載している。自然な口語体の日本語テキストを入力した方が品質が安定し、2〜3文程度の入力が最適だと報告している。

詳細

• モデル: Qwen/Qwen3-TTS-12Hz-1.7B-Base、HuggingFace からダウンロード
• 特徴: 3秒程度の音声サンプルでボイスクローン可能、多言語対応、商用利用可（Apache 2.0）
• 環境: DGX Spark aarch64 / CUDA 13.0 / Python 3.12 / uv 使用
• PyTorch インストール: uv pip install “torch==2.9.1” torchaudio –index-url https://download.pytorch.org/whl/cu130
• 音声サンプル準備: ffmpeg で 3秒目から10秒間を切り出し、モノラル 24kHz に変換
• Whisper（base モデル）で音声の文字起こし（ref_text）を取得
• ボイスクローン実行: model.generate_voice_clone(text, language, ref_audio, ref_text) → soundfile で WAV 保存
• DGX Spark 固有の CUDA OOM 対策: PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True と max_memory={0: “60GiB”} が必要
• 品質のコツ: ノイズ少ない単独話者の音声、自然な口語体日本語テキスト、2〜3文程度の入力が安定

DGX Sparkに xrdp + Tailscale でリモートデスクトップ環境を構築する

• URL: https://zenn.dev/karaage0703/articles/ad960088e1b94f
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: NVIDIA DGX Spark（Ubuntu 24.04 LTS、aarch64）にxrdpとTailscaleを組み合わせてリモートデスクトップ環境を構築する手順をまとめた記事だ。ARM64ではChrome Remote Desktopが非対応のため、セットアップが簡易なxrdpを選択し、外部アクセスはTailscaleで解決する構成を採用している。GNOME+GDM3環境ではWaylandを無効化してX11セッションに切り替える必要があり、dbus-x11のインストールとstartwm.shへのDBUS_SESSION_BUS_ADDRESS/XDG_RUNTIME_DIRのunsetが接続安定に欠かせない。Snap版Firefox/Chromiumはxrdpセッションのcgroup判定で起動できないため、ARM64公式.debが配布されているBraveへの切り替えで回避できる。

詳細

環境

• OS: Ubuntu 24.04.3 LTS / aarch64 / GNOME 46 + GDM3（Waylandがデフォルト）
• Tailscale: インストール済み

ARM64でのリモートデスクトップ選択肢

• Chrome Remote Desktop: x86専用でARM64非対応（2026年4月末時点でアナウンスなし）
• xrdp: RDPプロトコル、ARM64動作可、採用
• NoMachine/RustDesk/VNC: 動作可能だが設定がより複雑

セットアップ手順

1. sudo apt install -y xrdp dbus-x11（dbus-x11がないと接続後即切断）
2. sudo adduser xrdp ssl-cert（SSL証明書アクセス権限）
3. GDM設定でWayland無効化: /etc/gdm3/custom.confの#WaylandEnable=falseをコメントアウト解除
4. /etc/xrdp/startwm.shにunset DBUS_SESSION_BUS_ADDRESSとunset XDG_RUNTIME_DIRをtest -x /etc/X11/Xsessionの直前に追加（画面真っ黒・即切断を回避）
5. sudo systemctl enable --now xrdp
6. sudo systemctl restart gdm3でX11セッションへ切り替え（ログイン画面のギアアイコンで「Ubuntu」を選択）

クライアント

• macOS/iOS/iPadOS: Windows App（旧Microsoft Remote Desktop）
• Windows: 標準リモートデスクトップ接続
• 接続先: Tailscale IP（100.xxx.xxx.xxx）のポート3389

Snap版ブラウザ問題と回避策

• Snap版Firefox/Chromiumはxrdpセッションのcgroup（session-c12.scope等）をsnap-confineが拒否して起動不可
• 回避: Brave公式arm64 .debをインストール（Snap非依存）

ログ確認

• sudo journalctl -u xrdp -f
• sudo tail -f /var/log/xrdp.log
• sudo tail -f /var/log/xrdp-sesman.log

Skillsで実現する軽量パーソナルRAG

• URL: https://zenn.dev/karaage0703/articles/d7eaf62437185d
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: PostgreSQL + pgvector を使っていた MCP 版 RAG を廃し、SQLite + intfloat/multilingual-e5-small（384次元・約500MB）で動く軽量 RAG をClaude Code のSkillsとして実装した workspace-rag を紹介している。セットアップは uv sync のみで、常駐サーバーなしでも動作するCLIモードと、モデルをロードし続けることで検索を約9秒から約0.1秒に短縮できる常駐HTTPサーバーモードを備える。EMNLP 2024 の R²AG アイデアを参考に検索結果に関連度スコアを付与している。

詳細

• 前回の MCP RAG との比較: DB が PostgreSQL+pgvector（Docker 必須）→ SQLite（ファイル1つ）、モデルが multilingual-e5-large 1024次元→ multilingual-e5-small 384次元、インターフェースが MCP プロトコル → AI エージェントの Skills
• CLI コマンド例: uv run python workspace_rag.py search -w /path/to/workspace -q “クエリ”
• インデックス作成は初回のみ数分、以降は差分のみで数秒
• 検索結果は「関連度: 0.94 (高)」形式のスコア付きで出力（R²AG の簡易実装）
• CLIモードの課題: 実行ごとにモデルをロードするため1回の検索に約9秒（モデルロード8秒＋DB処理1秒）
• 常駐HTTPサーバー（workspace_rag_server.py）でモデルを常駐させると検索が約0.1秒に短縮
• systemd ユーザーサービスとして PC 起動時に自動起動する設定も可能
• Skills として利用する場合: SKILL.md とスクリプトを .claude/skills/ に置き、シンボリックリンクで全エージェント共通化できる

スタックチャン開発に必要な情報まとめ

• URL: https://zenn.dev/karaage0703/articles/f14b27ccb22737
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: M5Stack版スタックチャン（M5スタックチャン）の開発に必要なソフトウェアを、公式系・有力コミュニティ系・自作の3カテゴリに整理したリファレンス記事だ。顔描画・サーボ制御・音声合成・対話エンジンなど必要な部品ごとに既存OSSの選択肢を示しており、ししかわさんのstack-chan（TypeScript/Moddable）、M5Stack公式（C++）、Arduino向けライブラリ、ESP-IDF版、Home Assistant統合などリポジトリをスター数・ライセンス・対応ハードとともに一覧化している。2026-05-12のv1.4.0でGPL-3.0のSCServo_libがMITのFTServo_Arduinoに置き換えられたライセンス整理の経緯も詳述されている。

詳細

公式系リポジトリ

• stack-chan/stack-chan（Apache-2.0, ★約1400）: TypeScript+Moddable SDK。M5スタックチャンハードへの移植進行中
• stack-chan/stackchan-arduino（MIT, ★約25）: C++のArduinoライブラリ。v0.0.7からM5スタックチャン対応
• m5stack/StackChan（各ソースにSPDX MIT, ★約600）: C++。モバイルアプリ・ツール類も含む総合プロジェクト
• m5stack/StackChan-BSP（MIT, ★約14）: Arduino向けBoard Support Package

ライセンス整理の経緯

• 2026-05-11にissue #52でGPL-3.0のSCServo_lib同梱を指摘
• 2026-05-12のv1.4.0でMITのftservo/FTServo_Arduinoに置き換え完了

有力コミュニティ系

• ronron-gh/AI_StackChan_Ex（★約88）: LLM+STT+TTS Web API組み合わせ / Module LLMローカル化 / OpenAI Realtime API / AquesTalk同梱の4モードをbuild_flagで切り替え
• mongonta555系: M5Burner経由でワンクリック書き込み可能な初心者向け系統
• ciniml/stackchan-idf: ESP-IDFベースの別系統実装
• M5Stack × Home Assistant: ESPHome YAMLで家全体のデバイスとして統合

自作例（記事筆者のxangi-stackchan）

• M5Unified + M5Stack-Avatar + 自前SCServo実装の組み合わせ
• PC側のxangiがAI対話ロジックを全部持ち、M5をSTATUS/VOLUME/WAV/FACE/MOVEプロトコルで制御するドライバとして使用
• M5CoreS3単体・AtomS3R+Atomic Voice Baseにも対応

GitHub AppをAIエージェントに使わせる方法

• URL: https://zenn.dev/karaage0703/articles/f317cc3a51fba1
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: AIエージェントにGitHubを操作させる際の認証方法として、個人アカウントや PAT に代わる GitHub App の利用手順を解説している。GitHub App は権限をリポジトリ単位・操作単位で絞り込めるうえ、Installation Access Token は 1 時間で失効するため漏洩リスクが低い。コミットやPRがBot名義になることで操作の追跡も容易になる。Python の PyGithub を使ったトークン取得・自動再取得の実装例や、gh CLI との統合ラッパー、コンテナ運用の考え方まで網羅されている。

詳細

• 認証方式3種の比較: gh CLI 個人ログイン（手軽だが全権限を渡す）、Fine-grained PAT（リポジトリ単位可だが静的トークン）、GitHub App（動的トークン・Bot名義・最小権限）
• GitHub App 作成手順: Settings → Developer settings で登録、権限は Contents/Issues/Pull requests を用途別に設定、「Only on this account」を選択
• 秘密鍵（.pem）を生成し、chmod 600 で保護。App ID と Installation ID をメモ
• PyGithub でのトークン取得は3行: Auth.AppAuth → GithubIntegration → get_access_token(installation_id)
• トークンの寿命は1時間。長時間稼働 bot では GitHubAppAuth クラスで「残り5分未満になったら再取得」するキャッシュ実装を推奨
• gh CLI との統合: GH_TOKEN 環境変数に取得トークンを渡すラッパースクリプト（gh-app）で既存の gh コマンドをそのまま流用できる
• git commit 時のユーザー設定: APP_ID+APP_NAME[bot]@users.noreply.github.com 形式が GitHub 推奨
• コンテナ運用: .pem ファイルを読み取り専用でマウントし、GITHUB_APP_ID/INSTALLATION_ID を環境変数で渡す構成が安全

DGX Sparkで色々なローカルLLMを動かした比較結果

• URL: https://zenn.dev/karaage0703/articles/fcca40c614dffd
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: NVIDIA DGX Spark（GB10、ARM64、128GB統合メモリ）でOllama・vLLM・SGLangの各推論エンジンを使って複数のローカルLLMを動作確認し、速度・ツールコール精度・メモリ使用量・手軽さの4軸で比較した実測レポートだ。ツールコールが必要な場合はGemma4-26B-A4B-NVFP4+vLLMネイティブまたはQwen3.6-35B-A3B+Ollamaが高性能で推奨構成とされている。vLLM向けにはDGX Spark専用最適化ビルドvllm-custom（namake-taro/vllm-custom）のprecompiled wheelを使う方法と、pip wheel+パッチ適用の方法が詳述されている。Nemotron-Cascade-2のようにOllama公式ライブラリ未登録モデルのGGUF+カスタムModelfileによる起動手順も含まれている。

詳細

推奨構成

• ツールコール必要: Gemma4-26B-A4B-NVFP4+vLLMネイティブ（約48 tok/s）またはQwen3.6-35B-A3B+Ollama（約58 tok/s）
• 最速（ツールコール不要）: nemotron-3-nano+Ollama（約69 tok/s）、Nemotron-Cascade-2+Ollama（約72 tok/s）
• 大規模（128GBメモリ活用）: gpt-oss:120b+Ollama（65GB、約41 tok/s、ツールコール対応）

ツールコール評価方法

• テックニュースキュレーションツールと画像生成スキルの両方成功で○、片方で△、両方失敗で×

Ollama

• DGX Sparkにプリインストール済み、ollama run モデル名で即起動
• Nemotron-Cascade-2はOllama未登録のためGGUFダウンロード+カスタムModelfile（RENDERER/PARSER nemotron-3-nanoを指定）で対応
• nothinkタグは表示上非表示になるだけで速度は変わらない

vllm-custom sparkcustom（推奨vLLM導入方法）

• precompiled wheelでインストール: namake-taro/vllm-customのリリースページからaarch64 wheelを取得
• NF4量子化（MXFP4の改良版）とStream Loading（メモリ不足なしで巨大モデルを読み込み）が特徴
• –gpu-memory-utilizationは効かず、VLLM_KV_CACHE_MEM_MARGIN環境変数（MiB単位）で制御
• Ollamaと共存する場合はVLLM_KV_CACHE_MEM_MARGIN=30720（30GB）を推奨

vLLM（方法A: pip wheel+パッチ）

• vLLM cu130 wheelをインストール後、namake-taroのvllm_all.patchとflashinfer_cutlass_sfb_layout_fix.patchを適用
• パッチ適用後はFlashinfer/vLLM/torchinductorのキャッシュクリアが必須

vllm-customキー設定（Qwen3.5-27B起動例）

• --enable-auto-tool-choice --tool-call-parser qwen3_coder --default-chat-template-kwargs '{"enable_thinking": false}'

動作確認できなかった構成

• eelbaz/dgx-spark-vllm-setupは2026年3月時点でMOEカーネルのundefined symbolエラー等で動作不可
• nemotron-3-super+vLLM Dockerも動作せず

【GitHub Actions】actions/checkout には persist-credentials: false を設定するべき

• URL: https://zenn.dev/kou_pg_0131/articles/gha-checkout-persist-credentials
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitHub Actionsでactions/checkoutを使う際、デフォルトのpersist-credentials: trueのままではGitHubトークンが$RUNNER_TEMP以下の設定ファイルに平文同然の状態で残り、後続ステップから容易に抜き取られる危険性がある。persist-credentials: falseを設定することでチェックアウト後にファイルが削除され、後続ステップからのファイル経由トークン窃取を防げる。Git認証が必要な後続処理はgh auth setup-gitコマンドで都度参照する構成に切り替えることで安全性と利便性を両立できる。設定漏れはghasec・zizmor・ghalintといった静的解析ツールで自動検出可能であり、人的な見落とし防止としてCI組み込みが推奨される。

詳細

• 問題: actions/checkoutはデフォルト（persist-credentials: true）で$RUNNER_TEMP/git-credentials-.configを残す
• ファイルの内容: [http “https://github.com/”] extraheader = AUTHORIZATION: basic <Base64文字列> の形式で、デコードするとx-access-token:<GitHubトークン>が取れる
• 攻撃経路: リモートアクションの侵害やスクリプトインジェクションを経由してこのファイルを読まれる
• 対策: persist-credentials: false を設定するとチェックアウト完了後にファイルが削除される
• Git認証が必要な後続処理の対応:
  • gh auth setup-git コマンドを実行すると ~/.gitconfig にGitHub CLI経由の認証設定が追加される
  • 必要なステップにのみ env: GH_TOKEN: ${{ github.token }} を渡す構成
• 静的解析ツールによる検出:
  • ghasec: “persist-credentials: false” must be set in “with” (checkout-persist-credentials)
  • zizmor: artipacked ルールで検出
  • ghalint: checkout_persist_credentials_should_be_false ポリシーで検出
• 補足: disable-checkout-persist-credentials CLIで既存ワークフローを自動修正可能

【GitHub Actions】スクリプトインジェクションの実践例

• URL: https://zenn.dev/kou_pg_0131/articles/gha-script-injection
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitHub Actionsのrunブロック内で${{}}式を直接展開するとスクリプトインジェクションが可能になることを、PR タイトルとブランチ名を使った実際の攻撃例で示した記事。PRタイトルを「"; echo INJECTED"」にすると式が展開されて任意コードが実行され、ブランチ名では${IFS}でスペース代わりにして同様の攻撃が成立する。対策はrunブロック内で${{}}を使わずシェル環境変数経由で値を渡すことで、${{ env.* }}を使っても同様に展開されるため誤解を招きやすい。プライベートリポジトリも侵害されたGitHub App経由で攻撃可能であり、ghasec・actionlint・zizmor等の静的解析ツールで自動検出できる。

詳細

• 脆弱なパターン: run内で ${{ github.event.pull_request.title }} や ${{ github.head_ref }} を直接使用
• 攻撃例1（PRタイトル）:
  • タイトルを ‘"; echo INJECTED"’ に設定
  • 展開後: echo “PR title is “; echo INJECTED”” となり任意コードが実行される
• 攻撃例2（ブランチ名）:
  • ブランチ名を ‘main";echo${IFS}INJECTED"’ に設定（ブランチ名にスペース不可なので${IFS}で代用）
  • 展開後: echo “PR Head Ref is main”;echo${IFS}INJECTED"" となる
• 対策: 環境変数経由で渡してシェル変数として参照する
  • 誤: run: echo “${{ env.PR_TITLE }}” with env: PR_TITLE: ${{ … }} ← ${{ env.* }}も実行時に展開されるため不可
  • 正: run: echo “${PR_TITLE}” with env: PR_TITLE: ${{ … }} ← シェル変数を使う
  • github.head_refはGITHUB_HEAD_REFというデフォルト環境変数が既に用意されているので自前定義不要
• プライベートリポジトリも危険: Contents:Write + Pull Requests:Writeを持つ侵害済みGitHub App経由で攻撃可能（Workflows:Writeなしでも任意コード実行が成立）
• 静的解析による自動検出:
  • ghasec: script-injection ルール
  • actionlint: expression チェック
  • zizmor: template-injection ルール（confidence: High）
• 参考文献: 「GitHub CI/CD実践ガイド」第15章 GitHub Actionsのセキュリティ

GitHub Actions で参照するアクションはコミット SHA で固定するべき

• URL: https://zenn.dev/kou_pg_0131/articles/gha-should-be-pinned
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitHub Actionsでリモートアクションをコミット SHA固定にすべき理由を多角的に論じた記事。Gitタグやブランチはmutableなため、参照先リポジトリが侵害されると自身のワークフロー定義を変更していないのに悪意あるコードが実行されるリスクがある（tj-actions・reviewdog侵害事例を参照）。コミットSHAはimmutableなためこのリスクを低減でき、pinactで一発変換できる。「メジャーバージョンタグが便利」「Immutable Releasesがあれば安全」「コミットSHAを間違えると見分けがつかない」などの反論に対してもそれぞれ具体的に反証しており、なりすましコミットの検出にはzizmor、SHA固定の強制はリポジトリ設定で実現できる。

詳細

• 問題の本質: GitタグはMutableなため、アクション提供リポジトリが侵害されるとタグを書き換えられ、利用者側の変更なしに悪意あるコードが実行される
• 実際の事例: tj-actions・reviewdogが侵害されて大騒ぎになった事件（記事執筆時点から約1年前）
• 推奨: コミットSHAでアクションを固定し、インラインコメントでバージョンを記載
  • 良い例: uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
• ツール:
  • pinact run: タグ/ブランチ指定をSHA固定に自動変換（brew install pinact）
  • pinact run –update: 最新バージョンに更新
  • –verify オプション: コメントのタグとSHAの不一致を検出（pinactコメントより）
  • zizmor: impostor-commitルールでなりすましコミットSHAを検出
• リポジトリ設定による強制: “Require actions to be pinned to a full-length commit SHA” 設定で未固定ワークフローの実行をエラーにできる
• 反論への反証:
  • 「Immutable Releases有効なら安全」→ 全依存アクションおよびメジャーバージョンタグで有効とは限らない
  • 「メジャーバージョンタグが便利」→ 依存ライブラリを毎日自動更新mainにpushするのと同じリスク
  • 「コミットSHA間違いで見分けがつかない」→ zizmor impostor-commitで検出可能
• 注意: SHA固定はサプライチェーンリスク軽減の一手段であり、「SHA固定のみで完全に安全」ではない

GitHub Actions 向け静的解析ツールの紹介 (actionlint/ghalint/zizmor)

• URL: https://zenn.dev/kou_pg_0131/articles/gha-static-checker
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitHub Actions ワークフローの静的解析ツールとして actionlint、ghalint、zizmor の 3 つを紹介・比較している。actionlint は構文チェックや shellcheck/pyflakes 連携など文法系が充実しており、ghalint は job の permissions 必須化やコミット SHA 固定・persist-credentials: false 設定などセキュリティ系チェックに特化、zizmor も同様にセキュリティ重視の静的解析ツールとして位置づけられている。2026 年初頭の tj-actions/changed-files の Git タグ書き換え事件を背景に、これらのツールを組み合わせた自動化の重要性を説いている。

詳細

検証バージョン: actionlint 1.7.7、ghalint 1.2.3、zizmor 1.5.1

actionlint:

• インストール: brew install actionlint
• 主なチェック: 必須キー・キー重複チェック、${{ }} 構文チェック、shellcheck によるシェルスクリプト検査、pyflakes による Python スクリプト検査
• 使い方: 引数なしで実行すると .github/workflows/ 内の全ファイルを対象、ファイルパスの明示指定も可
• -format '{{json .}}' で JSON 形式の出力も可能

ghalint:

• インストール: brew install suzuki-shunsuke/ghalint/ghalint
• コマンド: ghalint run（Workflow チェック）、ghalint run-action（action.yml チェック）
• 主なチェック: job の permissions 設定必須化、コミット SHA 固定必須化、actions/checkout での persist-credentials: false 設定必須化

zizmor:

• セキュリティ観点の静的解析に特化（記事は zizmor の詳細部分で本文が切れているため全項目不明）

背景:

• tj-actions/changed-files や reviewdog/action-* の Git タグ書き換えによる悪意あるコード実行事件が動機
• アクション参照にコミット SHA 以外にも多数の考慮事項があり人力チェックには限界があるため自動化が必要

【GitHub Actions】コミット SHA で固定したアクションのバージョンを更新する

• URL: https://zenn.dev/kou_pg_0131/articles/gha-update-pinned-actions
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitHub Actionsでコミット SHA固定を運用した場合のバージョン更新負荷を、pinact・Dependabot・Renovateの3つの手段で自動化する方法をまとめた記事。pinact run –updateコマンドで手動一括更新ができるほか、Dependabot（dependabot.yml設定のみ）やRenovate（空設定でも動作）を使えばPRベースでの定期自動更新が実現できる。いずれもコミットSHAとインラインコメントのバージョンタグを同時に更新する。ただしコミットSHA固定のアクションはDependabotセキュリティアラートの対象外になるため、minimumReleaseAgeやcooldownを設けて即日アップデートを避ける運用が推奨される。

詳細

• 手動更新: pinact run –update（全ワークフローのアクションを最新版コミットSHAに一括更新。インラインコメントのバージョンタグも同時更新）
• pinactの対象ファイル: .github/workflows/*.yml, action.yml, action.yaml, サブディレクトリのaction.{yml,yaml}まで（任意ファイルも引数指定可）
• Dependabot設定（.github/dependabot.yml）:
  • package-ecosystem: github-actions, directory: / を指定するだけ
  • デフォルト対象: .github/workflows/*.yml と リポジトリルートのaction.yml のみ
  • サブディレクトリのaction.{yml,yaml}は追加エントリで個別指定が必要
• Renovate設定: {} 空設定でもgithub-actionsマネージャがデフォルト有効
  • 対象: .github/workflows//*.yml, .github/actions//*.yml, **/action.yaml など広範囲をカバー（Dependabotより広い）
• 重要な制限事項: コミットSHA固定のアクションはDependabot脆弱性アラートの対象外（セマンティックバージョニング指定のみが対象）
  • RenovateのvulnerabilityAlertsもDependabotアラートに依存するため同様の制限あり
  • 対策: minimumReleaseAge（Renovate）またはcooldown（Dependabot）でリリース直後の即日更新を避ける

セキュリティ重視の GitHub Actions 静的解析ツール「ghasec」の紹介

• URL: https://zenn.dev/kou_pg_0131/articles/ghasec-introduction
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitHub Actionsのセキュリティに特化した静的解析ツール「ghasec」の作者による紹介記事。既存のactionlint・zizmor・ghalintをそれぞれの良い部分を統合して一本化したツールで、v0.10.0時点で20個のセキュリティルールをサポートする。デフォルトパーミッション未設定・タイムアウト未設定・コミットSHA未固定・persist-credentials未設定・スクリプトインジェクション・なりすましコミットなどを検出でき、Markdown形式出力でAIエージェントに修正を委譲することも想定している。goccy/go-yamlでYAMLをパースし、ルールごとに個別の検出ロジックを実装した構造で、GitHub Actionsワークフロー内での実行用アクションも提供している。

詳細

• 開発背景: actionlint・zizmor・ghalint の3ツールを毎回実行する手間を解消するため、それぞれの好みの部分を統合して作成
• インストール: brew install koki-develop/tap/ghasec / go install github.com/koki-develop/ghasec@latest / Docker実行も可能
• デフォルト対象ファイル: .github/workflows/*.{yml,yaml} と **/action.{yml,yaml}
• 主な検出ルール（v0.10.0時点で20ルール）:
  • default-permissions: 権限が明示されていない（permissions: {}未設定）
  • job-timeout-minutes: ジョブのタイムアウト未設定（デフォルト360分）
  • checkout-persist-credentials: persist-credentials: false未設定
  • unpinned-action: コミットSHA未固定のリモートアクション参照
  • script-injection: run内で ${{}} を直接使用
  • impostor-commit: リポジトリに存在しないコミットSHAの参照
• オンラインモード: –online フラグでGitHub APIを使うルールも有効化（トークンはGHASEC_GITHUB_TOKENまたはGITHUB_TOKEN環境変数）
• 無視コメント: # ghasec-ignore または # ghasec-ignore:ルール名 で個別無効化（無意味なignoreはエラー）
• 出力フォーマット: デフォルトはSHA/行番号付きの詳細表示（シンタックスハイライト付き）、–format=markdownでAIエージェント連携向け出力
• 表示ライブラリ: 自作のkoki-develop/annotate-go（シンタックスハイライト: alecthomas/chroma）

GitHub Actions の依存関係を再帰的に出力する「ghatree」の紹介

• URL: https://zenn.dev/kou_pg_0131/articles/ghatree-introduction
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitHub Actions ワークフロー内で使用しているアクションの依存関係を再帰的に取得して出力するツール ghatree が公開された。--json フラグで依存ツリーを JSON 出力でき、直接使用しているアクションが内部依存しているアクションまで網羅できる。GitHub の Enforce SHA Pinning 機能は推移的な依存まで対象にするため、手動での特定が困難だった間接依存のコミット SHA 未固定アクションを ghatree で自動検出できる。

詳細

インストール・実行: npx ghatree@latest（npm パッケージ）

主なオプション:

• --repo <owner/repo> — 特定リポジトリを指定（デフォルトはカレントディレクトリの .github/workflows）
• --json — 依存ツリーを JSON 形式で出力
• GITHUB_TOKEN 環境変数で GitHub API トークンを設定（プライベートリポジトリや Rate Limit 回避に利用）

Enforce SHA Pinning との関係:

• GitHub の Enforce SHA Pinning を有効にすると直接参照アクションだけでなく推移的な依存アクションもコミット SHA 固定が必要になる
• 例: cli/gh-extension-precompile 経由で内部依存している actions/setup-go@v5 などが未固定だとワークフロー実行が失敗する
• ghatree の JSON 出力を Bun Shell スクリプトで再帰探索し SHA 未固定のアクションをログ出力するスクリプト例が記事に掲載されている

tj-actions/changed-files や reviewdog/action-* の Git タグ書き換え事件を背景に、アクションの推移的依存まで含めたセキュリティ管理の重要性が高まっている。

TypeScript で GitHub Actions ワークフローを記述する「ghats」の紹介

• URL: https://zenn.dev/kou_pg_0131/articles/ghats-introduction
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: TypeScript で GitHub Actions ワークフローを記述して YAML にビルドする ghats が公開された。Workflow クラスと Job クラスを使ってワークフローを定義し ghats build を実行すると YAML が生成される。ghats install <action> でリモートアクションをインストールすると型補完が有効になり、action() 関数を通じて使用するとビルド時にコミット SHA が自動で固定される仕組みを持つ。アクションのバージョン管理は actions.json に記録され actions-lock.json にコミット SHA が保存される。

詳細

インストール: npm install -D ghats

基本的な使い方:

• ワークフロー定義ファイルは .github/workflows/*.ts に作成する
• Workflow と Job を ghats からインポートして定義
• ghats build でワークフロー YAML をビルド（生成ファイルは自動生成コメント付き）

リモートアクションの型サポート:

• npx ghats install actions/checkout でアクションをインストール
• action() 関数を使ってリモートアクションを参照すると入力値の型補完が効く
• ビルド時にコミット SHA が自動で固定されるため、ワークフロー定義内でバージョンを明示的に指定しなくてよい

生成されるファイル:

• .github/workflows/actions.json — インストールしたアクションとバージョンの対応
• .github/workflows/actions-lock.json — コミット SHA のロックファイル

セキュリティ上の意義:

• Git タグは書き換えられる可能性があるためコミット SHA 固定が推奨されているが、手動での管理は手間がかかる
• ghats を使えばバージョン指定は actions.json で一元管理でき、ビルド時の SHA 固定が自動化される

ghats 自体のリポジトリの GitHub Actions ワークフローも ghats で記述されている。

複数 AI エージェントの MCP サーバーの設定を一元管理する「mmcp」の紹介

• URL: https://zenn.dev/kou_pg_0131/articles/mmcp-introduction
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude Code、Codex CLI、Gemini CLI、Cursor など複数の AI エージェントが個別に持つ MCP サーバー設定を ~/.mmcp.json で一元管理するツール mmcp が公開された。mmcp add でサーバーを追加し mmcp apply を実行するだけで、各エージェントのフォーマット（JSON や TOML）の差異を吸収して設定を配布できる。TOML 形式の Codex CLI への適用には @shopify/toml-patch を使いコメントを保持しながら更新する工夫が施されている。v0.3.1 時点で Claude Code、Claude Desktop、Codex CLI、Cursor、Gemini CLI の 5 エージェントに対応している。

詳細

インストール: npm install -g mmcp

主なコマンド:

• mmcp add -- <name> <command> [args...] — MCP サーバーを追加（--env KEY=VALUE で環境変数指定も可）
• mmcp list — 登録済み MCP サーバーを一覧表示
• mmcp agents add <name...> — 適用対象エージェントを追加
• mmcp agents list — 登録済みエージェントを一覧表示
• mmcp apply — 全エージェントの設定ファイルに MCP 設定をマージ

設定ファイルは ~/.mmcp.json に保存され直接編集も可能

対応エージェントと設定ファイルパス（v0.3.1）:

• Claude Code: ~/.claude.json
• Claude Desktop: macOS ~/Library/Application Support/Claude/claude_desktop_config.json、Windows %APPDATA%\Claude\...
• Codex CLI: ~/.codex/config.toml（TOML 形式。@shopify/toml-patch でコメント保持しながら更新）
• Cursor: ~/.cursor/mcp.json
• Gemini CLI: ~/.gemini/settings.json

仕組み: .mmcp.json の内容を各エージェントの設定ファイルの MCP サーバー設定部分にマージするだけ。作者は実装の約 8 割を Codex CLI に委譲したと述べている。

OpenAI Privacy Filter を pre-commit フックに入れて個人情報のコミットを防ぐ

• URL: https://zenn.dev/kou_pg_0131/articles/opf-pre-commit
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: OpenAIが2024年4月に公開したOpenAI Privacy Filterをpre-commitフックに組み込み、個人情報を含むコミットを自動的にブロックする手法を試した実践記録。ローカルで動作するモデルで、pipでGitHubから直接インストールしてopfコマンドで使用できる。staged差分の追加行をgit diffで抽出してopf redactに渡し、検出されたPIIのスパン数が1件以上あればコミットを失敗させるbashスクリプトとして実装している。英語・日本語の人名や口座番号などの検出には対応するが、実行に数秒〜数分かかるためファイル種別で適用範囲を絞らないと運用が難しいとも指摘している。

詳細

• ツール: OpenAI Privacy Filter（OPF） - 2024年4月公開、ローカル動作、PyPIには未掲載
• インストール: pip install git+https://github.com/openai/privacy-filter.git
• 基本コマンド: opf redact –device cpu –text-file <ファイル>
• 出力形式: text（デフォルト）またはjson（–format json）。json形式でラベル・位置・元テキスト・プレースホルダーを取得可能
• 検出ラベル例: private_person、account_number、secret、private_date など
• 検出実績: 英語・日本語の人名、クレジットカード末尾4桁（account_numberとして主に検出）
• pre-commitフック実装の概要:
  • git diff –staged -U0 で追加行を抽出
  • opf redact –format json に標準入力で渡す
  • jqでspan_countを集計し、合計0ならexit 0
  • 検出ありの場合は先頭2文字を残してマスクして表示し、exit 1
• 実行パフォーマンスの問題:
  • CSVファイル10行程度: 約5秒
  • Webアプリ数百行の機能実装: 3分近くかかる場合も
  • 対象ファイル種別の絞り込みが実運用では必須
• 精度: 完璧ではなく、クレジットカード末尾4桁の一部は検出漏れあり

Safari は file input に HEIC 画像を入力すると自動的に画像形式を変換することがある

• URL: https://zenn.dev/kou_pg_0131/articles/safari-input-file-heic
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Safari での <input type="file"> に HEIC 画像を入力したときの挙動を実機検証した記録で、macOS Safari と iOS Safari で動作が大きく異なることが判明した。macOS Safari では accept 属性に image/heic が含まれている場合はそのまま HEIC が入力されるが、含まれていない場合は accept 属性の先頭で変換可能な形式に自動変換される。iOS Safari は accept 属性の値に関わらず常に JPEG に変換されるが、これは Safari 固有の挙動ではなく iOS 版 WebKit の仕様と考えられている。ファイル形式が変わる際はファイルサイズとファイル名も変化するため、バックエンドでの受け取り側に影響が出る。

詳細

検証環境: macOS Safari 17.6、iOS Safari 604.1

macOS Safari の挙動:

• accept 属性に image/heic が含まれる場合（"image/heic"、"image/*"、"" 含む）→ HEIC がそのまま入力される
• accept 属性に image/heic が含まれない場合 → accept 属性の先頭にある変換可能な形式に自動変換される
  • 例: "image/jpeg,image/png,image/gif" → JPEG に変換
  • 例: "image/png,image/gif,image/jpeg" → PNG に変換（先頭が変換基準）

iOS Safari の挙動:

• accept 属性の値に関わらず常に JPEG に変換される
• Chrome、Firefox、Edge も同様の挙動 → iOS 版 WebKit の仕様の可能性が高い（EU 版の代替レンダリングエンジン環境では挙動が異なる可能性もある）

変換時の影響:

• ファイル形式の変化に伴いファイルサイズも変わる
• ファイル名も変わる（拡張子が変更される）
• バックエンドでの Content-Type 判定やファイルサイズ検証に影響が出る可能性がある

実用上の注意点:

• ユーザーが HEIC を選択した場合でも、accept 属性の設定次第で受け取る実際のフォーマットが変わることを想定してサーバーサイドを実装する必要がある

webpack to Rspack ~ Rspack移行の結果と注意点 ~

• URL: https://zenn.dev/lapras_inc/articles/b2df9989fe2c6e
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: LAPRASがwebpackからRspackへビルドツールを移行した経緯と、prodビルドで発生した3つの具体的な不具合への対処を詳述した記事。Rspackはwebpackプラグインをそのまま利用できる互換性を持ち、公式の移行ガイドに沿って進めるだけでdevelopmentビルドは通った。一方productionビルドではCSSファイルのハッシュ長不一致・node_modulesからのsassインポートが除外される問題・同名で内容が異なるJSファイルが生成されるバグが発生し、それぞれ設定変更とローダー置換で回避した。ビルド時間はdevelopment・productionともに約半分以下に短縮されている。

詳細

移行の動機と対象

• django-webpack-loader経由でwebpackに依存した構成のため、ViteやRollupへの移行が困難
• Rspackはwebpackプラグインをそのまま利用できるため移行を選択
• Rspack v1.0.0は2024年8月リリース

ビルド時間の比較（Apple M1 Max, TypeScript 390ファイル + Vue.js 360ファイル）

• developmentビルド: webpack 18.0s → rspack 8.0s
• productionビルド: webpack 24.5s → rspack 8.7s

prodビルドで発生した3つの問題と対処

① CSSハッシュ長不一致（画面真っ白）

• CssExtractRspackPluginが32文字ハッシュを出力するが、JSから参照する側は20文字を期待
• 対処: filename を [name].[contenthash:20].css に固定

② node_modulesのsassスタイルが除外される

• builtin:lightningcss-loader の最適化により~hoge/dist/style.cssのインポートがバンドルから除外
• 対処: postcss-loader に変更（ビルド速度がやや低下）

③ 同名で内容が異なるJSファイルが生成される（キャッシュ汚染）

• [chunkhash] 指定にもかかわらずハッシュ衝突が発生、CloudFrontでキャッシュ事故が発生
• 対処: [contenthash] に変更（おそらくRspackのバグ）
• 再発防止のためCIでビルド結果の同名ファイル内容差異を検出するスクリプトも追加

子供が自分でEC2のマイクラサーバーを起動できるように家庭用Alexaスキルを作ってみた

• URL: https://zenn.dev/lapras_inc/articles/e9502a8f8d2cc3
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 子供が声でEC2上のマイクラサーバーを操作できるよう、Alexaカスタムスキルを作成した事例。Amazon Developer ConsoleでスキルとインテントおよびスロットをDSLで定義し、エンドポイントにServerless Framework製のLambda関数を設定する構成。ServerNameとOperationNameの2スロットを持つServerOperationIntentを作成し、Alexaのオートデリゲート機能でスロット未入力時に自動で補完対話を行う。子供の不在時や自分の不在時にも声だけでサーバー起動・停止・状態確認が可能になり、父親の技術を子に見せる機会にもなった。

詳細

Alexaスキル開発の手順

1. Amazon Developer Consoleでスキルを作成

• ホスティングサービスで「独自のプロビジョニング」を選択（AWSのLambdaをエンドポイントとして使用するため）
• 通常のAWSアカウントとは別にAmazon Developerアカウントが必要

2. インテント・スロット・ダイアログの設計

• SERVER_NAME と OPERATION_NAME の2スロットを定義
• ServerOperationIntent でこれらのスロットを利用
• オートデリゲート機能により、ユーザーがサーバー名を省略した場合もAlexaが自動的に補完対話を実施
• 各スロットに類語・サンプル発話を設定し発話理解精度を向上

3. Lambda関数の実装（Serverless Framework）

• LaunchRequestHandler: スキル起動時の応答
• ErrorHandler: エラー処理
• helpIntentHandler: ヘルプ対話
• stopIntentHandler: スキル終了
• ServerOperationHandler: EC2操作のメインハンドラ（サーバー名と操作種別をマップで定義）

4. デプロイとテスト

• Serverless Framework でデプロイ後、エンドポイントURLをAlexaスキルに設定
• Developer ConsoleのテストページまたはEchoデバイスから動作確認

運用実績

• 「ポケモン」「サバイバル」の2サーバーを家族で運用中

LAPRASのフロントエンド改善活動ふりかえり [2024年]

• URL: https://zenn.dev/lapras_inc/articles/lapras-frontend-2024
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: フロントエンド専任エンジニアがいないLAPRASで、有志エンジニアが週1回集まるフロントエンド改善委員会を運営し、2024年に実施した複数の技術的移行をまとめた記事。JestからVitestへの移行でCIテスト実行時間が約1/3に短縮、webpackからRspackへの移行でビルド時間が約1/2に削減、SWRVからTanstackQueryへの非同期状態管理の移行も実施した。TypeScript型エラーの継続的解消やE2Eテスト（Vitest Browser Mode）の試験導入、Storybookの6系から8系へのアップデートも進めている。

詳細

組織背景

• フロントエンド専任エンジニア0人、2015年ファーストコミット、TypeScript + Vue3のSPA
• 有志のフロントエンド改善委員会が週1回1時間集まって改善活動を継続

完了した主な移行と成果

• Jest → Vitest: CIフロントエンドテスト実行時間が約1/3に短縮、ES Modulesのパッチ不要に
• SWRV → TanstackQuery: SWRVのメンテナンス停滞・機能不足が移行の動機
• webpack → Rspack: devビルド18.0s→8.0s、prodビルド24.5s→8.7s（Apple M1 Max）
• Storybook 6系 → 8系: Vue CLIビルドからViteビルドへも同時移行
• script setupの布教: Option API・Composition APIが混在していた状態をCoding Guideで整理

進行中・検討中

• Vuexからの非同期状態管理移行（TanstackQueryへ）
• yarn 1系からnpmへの移行（モジュール解決依存問題が障壁）
• AxiosからFetchへの書き換え
• E2Eテスト導入（Vitest Browser Mode試験導入中）
• Core Web Vitalsの改善（mizchiの公開パフォーマンスチューニング動画で指摘）

TypeScript対応

• PRごとに型エラー差分をGitHub ActionsでコメントするCI整備

SaaS公式MCPサーバーをリリースして得た学び

• URL: https://zenn.dev/lapras_inc/articles/lapras-mcp-server
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: エンジニア向けポートフォリオ・転職サービス LAPRAS が公式 MCP サーバーをリリースし、その設計判断と開発で得た失敗の学びをまとめた記事。公式 TypeScript SDK のみを採用して将来の仕様変更への追従性を確保し、tool 定義をファイル分離することでテストと拡張性を高める設計を採った。コンテキスト長の制限による API 失敗、複雑な API インターフェイスによる LLM の誤操作でデータが消える問題、LLM が改行をエスケープした文字列を出力してしまう問題など、MCP サーバー固有のハマりどころが詳述されている。更新系 tool の提供ではサービスとしてどこまで品質を担保するかという設計上の問いも生じている。

詳細

開発時の判断と理由:

• 公式 TypeScript SDK のみ採用: fastmcp 等のサードパーティ製は将来の仕様変更追従リスクがあるため
• リモート MCP は不採用: 採用例が少なく認証構築に工数がかかるため。現在なら Streamable HTTP Transport で検討の余地あり
• tool 定義をファイル分離: index.ts で一括登録する設計で、個別テストと新 tool 追加が容易になった

監視体制:

• MCP 専用 API を新規作成（既存 API と分離）
• AWS WAF でエンドポイントごとのレートリミット設定
• Datadog で MCP 用 API のリクエスト監視・アラート設定

開発中の失敗と対処:

1. コンテキスト長の問題: 大量データを返す tool が Claude Desktop 無料版（コンテキスト制限あり）でのみ失敗。per_page 縮小・不要フィールド除外で対処
2. 複雑な API インターフェイスによるデータ消失: バルク create/delete/update という一般的でない API を踏襲したところ LLM が意図せぬ削除を実行。force: true ガードを試みたが LLM が確認なしに指定してしまい断念。素直な部分更新 API に変更して解決
3. LLM 出力の改行エスケープ問題: LLM がパラメーターに \n を含めてしまい表示が崩れた。MCP サーバー側でクレンジング処理を追加して対応

設計上の議論:

• 更新系 tool では仕様的バリデーションは API 側で行えるが、内容の正当性は担保不可能
• 修正できる操作（職歴更新等）はリスクを取ってリリース。やり直しの効かない操作（応募・メッセージ送信等）は慎重に判断すべき

Gemini × NotebookLM 連携で「自分専用エージェント」を量産する：蓄積した履歴を血肉化する究極の活用術

• URL: https://zenn.dev/minipoisson/articles/2806b4a0865acb
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Geminiの全チャット履歴をNotebookLMに集約し、そのノートブックを知識源として参照する専用Gem（カスタムエージェント）を4種類作成することで、目的別の専属AIアシスタントをワンクリックで起動できる仕組みを構築した事例だ。2026年1月に利用可能になったGemini上でのNotebookLM連携機能を活用しており、指示文（System Instruction）を短く保ちながら数百万トークン規模の背景知識をエージェントに持たせる点が特徴となっている。Zenn執筆支援、note向けエッセイ支援、ナレッジ検索、自己分析コーチの4Gemを構築し、使えば使うほど知識ベースが充実して精度が上がるサイクルを設計した。

詳細

構成の核心

• NotebookLM: 過去のGeminiチャット履歴（Markdown化済み）を格納する長期記憶
• Gems: 役割・システム指示を与える人格層
• 2026年1月から利用可能なGemini上でのNotebookLM直接参照機能で両者を接続

作成した4つのGem

• Zenn執筆支援: 技術的正確性と再現性を重視したテクニカルライター役
• note向け支援: エッセイ的・日常的な文体への変換。技術より背景の物語を優先
• ナレッジ検索機: 推測を禁止し、日付・コード・手順を正確に抽出することに特化
• 自己分析コーチ: エラー傾向・スキルの得意不得意・次の学習ステップを客観的に提案

設計ポイント

• Geminiのカスタム指示最適化ボタンで断片的な指示文をプロフェッショナルな形式に書き換え可能
• Gemの知識として複数のNotebookLMノートブックを指定できるため、分野別の知識ベース分割も可能
• 日々の会話がNotebookLMを更新し、Gemの精度が自動的に上がるフィードバックループを形成

絶望的な制約下で挑む「Excel帳票フォントサイズ調整」の完全自動化

• URL: https://zenn.dev/minipoisson/articles/3091ff2bb517ac
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: マクロ禁止の.xlsxと改修不可の業務システムという二重制約下で、Excel帳票の報告書フォントサイズを自動調整する仕組みを構築した実装レポートだ。フォントサイズ算出はマクロ付き別Excelで行い、結果をCSV経由で業務システムに渡す。帳票側はIF関数とFILTERXML関数を組み合わせたサイズ別スイッチング領域を印刷外に用意し、図のリンク貼り付けで表示領域に重ねることでマクロなしのフォント切り替えを実現している。409.5ptという行の高さ上限も縦結合セルで回避しており、1日1〜2時間の手作業削減とヒューマンエラー撲滅を達成した。

詳細

制約条件

• 帳票は.xlsx（マクロ不可）、業務システム側はベンダー製で改修不可
• 業務システムが書き込めるのはデータ流し込み用シートへの値のみ

フォントサイズ算出（マクロあり別Excel）

• FILTERXML関数で段落ごとにセルを分割（Excel 2019以前でも使用可）
• AutoFitを利用してセル高さを計測、枠に収まるまで1pt刻みでサイズを下げるループをVBAで実装
• 画面と印刷のズレを考慮し各段落末尾に1文字追加する安全マージンを設定
• 算出されたフォントサイズをCSVで出力し業務システムへ登録

帳票側の表示切り替え（.xlsxのみ）

• 印刷外領域にフォントサイズ別のセル領域を用意（IF関数でサイズが一致するセルだけに本文を入れる）
• 縦結合セルで409.5ptの高さ上限を回避
• 各領域を図のリンク貼り付けで印刷領域に重ねて配置（文字列ではなくレンダリング済み画像として扱われるため255文字制限が消える）
• テキストボックスでは255文字制限に阻まれたため図のリンク貼り付けへ変更した経緯あり
• 目盛線のチェックを外すことでPDF出力時の薄いグレー縁問題を解決

運用上の工夫

• 査読記録の自動生成とフォントサイズ登録をCSV出力で抱き合わせ、登録漏れを構造的に防止

Gemini・Claude・ChatGPT・Copilot の4つのAIにそれらの使い分けを聞いたら、全員が自分をハブだと思っていた

• URL: https://zenn.dev/minipoisson/articles/ai-self-cognition
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Gemini・Claude・ChatGPT・Copilotの4つのAIの全チャット履歴を統合したNotebookLMに、各AIの使い分けについて横断的な分析を依頼した考察記事。結果として、4者全員が自分を「思考・開発プロセスの中心（ハブ）」として位置づけ他のAIを補完的な部品と見なす構造的な自己評価インフレが確認された。とりわけCopilotの自己評価（設計から実装・テスト・レビューを統括するメインエージェント）と他者からの評価（エディタ内リアルタイム補完の実装担当）の乖離が最も大きかった。一方で「全会一致で認められた長所」も存在し、Geminiの情報収集・Claudeの大規模コードベース読解・ChatGPTの壁打ち・CopilotのIDE内インライン補完はいずれも他者から認められている。

詳細

• 調査方法: Gemini・Claude・ChatGPT・Copilotの全チャット履歴を同一NotebookLMノートブックに統合し、各AIの使い分け自己申告と他のAIからの評価を横断分析
• 自己評価の構造:
  • Gemini自己評価: Googleエコシステムとロングコンテキストでワークフロー全体のハブ・万能分析官
  • Claude自己評価: 日常的な深い検討・ライティング・コーディング設計の「主軸」
  • ChatGPT自己評価: 思考の構造化・抽象化・再設計を担う「思考を設計するAI」
  • Copilot自己評価: 設計から実装・テスト・レビューを一気通貫で主導する「万能型メインエージェント」
• 他者評価との乖離が最大なのはCopilot: 自称「設計統括」→他3者からは「タイピスト/補完/実装担当」
• 全会一致で認められた長所:
  • Gemini: 大量情報収集・探索の初動フェーズ
  • Claude: 大規模コードベース読解と論理的・洗練された推敲（Copilotが「圧倒的に強い」と評価）
  • ChatGPT: 対話を通じた意図の引き出しと壁打ち（意思決定のレビュー相手）
  • Copilot: IDE内インライン補完とリアルタイム実装支援（実務の実装パートナー）
• 自己評価インフレが生じる要因: ユーザー利便性最大化の設計上の性質、開発元からの自己ブランドの強調指示、学習データの自社サービスへの正のバイアス
• 実用的結論: 自己評価よりも「全会一致で認められた長所」を軸に使い分けるのが最も信頼性が高い
• この発見の意義: 単一AIとのチャットでは絶対に得られない俯瞰視点。複数AIの全履歴を横断的に問い合わせることで初めて可能になった分析

AIスライド翻訳の制約マップ：Google・DeepLのAPI vs Web UIを実験して分かったこと（2026）

• URL: https://zenn.dev/minipoisson/articles/ai-slides-i18n-l10n-map
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: AIスライド翻訳における各翻訳手段の対応可否を実験した比較記事。PNG画像・PDF・PPTXの各ファイル形式と、Google翻訳WebUI・DeepL WebUI・Google Cloud Translation API・DeepL API・Vision API+Pillowの組み合わせ別に実際に試した結果をまとめている。最大の混乱ポイントとして、同じ「翻訳」でもファイル形式と渡し方によって結果が大きく異なることを整理した。特にGoogle Cloud Translation APIはPNG画像に非対応（400エラー）で、DeepL APIはPNG画像に対応しているという差異が実務上重要な判断材料となる。文字消しツール（Adobe Express・Canva・Photoshop・IOPaint）の比較も含む。

詳細

手段別評価表の要点

PNG画像内テキストが翻訳される手段:

• Google翻訳 Web UI 画像モード（手動・無料・OCR+背景補完+再描画を内部エンジンで一括処理）
• DeepL API の translate_document に PNG を直接渡す（自動化可能・月50万文字無料）
• DeepL Web UI（手動・月3ファイル無料）

PNG画像内テキストが翻訳されない手段:

• Google Cloud Translation API に PNG を渡す → 400エラー（形式非対応。.docx/.xlsx/.pptx/.pdf/.rtf/.html/.txt のみ対応）
• PPTX/PDF の中の「画像として埋め込まれた」テキスト（どの手段でも非対応）

Google翻訳 Web UI が動く理由: 内部の非公開レンダリングエンジンを使用しているためでAPIとして提供されていない。

Vision API + Pillow 自前実装: 動作するが背景を単色矩形で塗りつぶすため Magic Enhance のグラデーション背景には馴染まない。実用性は低い。

DeepL API vs Google Cloud Translation API（PPTX/PDF翻訳での比較）:

• DeepL API: PNG画像対応・月50万文字無料枠・セットアップが軽い（APIキー取得+pip install）・対応言語約30
• Google Cloud Translation API: PNG非対応・PPTXはページ課金（$0.08/ページ・無料枠非適用）・GCPプロジェクト設定が必要・対応言語100以上

日本語など約30言語が対象ならDeepL APIが総合的に有利。Excelファイルの翻訳はDeepL APIも対応しておりGCPの無料枠も適用される（記事公開後に自己検証で判明した訂正事項）。

文字消しツール比較:

• Adobe Express 無料: 月25クレジット、品質◎
• Adobe Express プレミアム: 1,100円/月・月250クレジット・月払い可能（解約はAdobeサイト直接が推奨）
• IOPaint（ローカルAI・無料・無制限）: pip install iopaint / iopaint start –model=lama でブラウザ操作。単純背景では Adobe Express と遜色ない品質。

AIスライドをi18n/l10nで設計する：Magic Enhanceのデザインを編集可能な現地語版にする

• URL: https://zenn.dev/minipoisson/articles/ai-slides-i18n-l10n-pipeline
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Google SlidesのMagic Enhance（AIデザイン生成）で作ったスライドを、編集可能な多言語版に変換するパイプラインの設計思想を解説するハブ記事。パイプラインの本質は「背景とテキストの分離」で、AIが生成した最高のデザインを維持しながらテキストを自由に翻訳・編集できる状態を作る。英語をソース言語にする根拠として、英語は1文字あたりの情報量が少なくデザインに余白が生まれやすいため、英語から現地語への変換が「安全なダウンサンプリング」になるという考え方を提示している。7種類のバージョン比較（ドラフト・Enhanced・テキスト載せ直し・DeepL翻訳・Google翻訳・手動翻訳・AIと練り上げた版）の結果、AIとの対話で練り上げた版が最も自然だったと報告している。

詳細

2026年4月時点の状況（記事の前提の変化）

• 2026年1月当時の問題（日本語Magic Enhanceで漢字の形が崩れる）は2026年3月時点で解消
• 2026年4月2日のGemini in Google Slidesアップデートで英語US環境のみテキスト編集可能な生成が開始
• ただし新機能はアカウントの言語・地域設定に依存し、ユーザー側で選択できない

ワークフロー全体（6ステップ）

フェーズ1: マスタースライド作成

1. 英語でドラフト作成（テキストと最小限の図表のみ。元ドラフトをそのまま残しておくと後でテキストコピーに使える）
2. Magic Enhanceで各スライドにデザインを適用
3. PPTXでダウンロード
4. PowerPointでドラフトスライドを削除 → PNG一括書き出し
5. Adobe Expressの生成塗りつぶし（Generative Fill）で文字部分を消去して下地画像を作成
6. 下地画像スライドにテキストボックスを配置してマスタースライド完成

フェーズ2: 現地語版の生成（方針A or B）

• 方針A（大量翻訳・速さ優先）: PPTX を DeepL API または Google翻訳に渡して一括翻訳
• 方針B（精密翻訳・品質優先）: AIと現地語の文言を練り上げてテキストボックスに貼り付け

翻訳7バージョン比較の重要な発見

DeepL（④）と Google翻訳（⑤）の問題例:

• “Automated Localization” をGoogle翻訳が「自動位置特定」と訳した（localizationとlocateを混同）
• DeepL は文法的には自然だが、日本語として見直すと大幅に変えたくなる

手動翻訳（⑥）の問題: 英語原文に引きずられて学術的な表現になりがち。

AIと練り上げた版（⑦）の例:

• “Manual Review” → 「目視確認」（文脈は「自動処理パイプラインとの対比」）
• “Phase 1: Creating the Clean Template” → 「第１段階：文字のない下地の作成」

翻訳の課題の本質: 「翻訳して」と頼めば原文に忠実な訳を返すが、「この文脈でこの意図を現地語話者に伝えるには何と言うか」と問えば全く違う答えが返ってくる。

3手法の判断フロー:

• 現地語環境で作業・頻繁に編集 → 現地語でEnhanced直接適用
• 英語US設定が使えて出力に満足 → 新機能Enhanceで生成→翻訳
• 英語デザインを確実に確保・後から編集・数式あり → 本パイプライン

AIスライドの背景とテキストを分離する実践：Adobe Express＋DeepL APIで作る編集可能な現地語版

• URL: https://zenn.dev/minipoisson/articles/ai-slides-l10n-adobeexpress-deepl
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Google SlidesのMagic Enhance生成スライドを編集可能な多言語版に変換するパイプラインの実装詳細を解説する。Adobe Expressの生成塗りつぶし機能で文字を消去して下地画像を作り、DeepL APIでPPTXを翻訳するという2フェーズの構成をとる。DeepL APIのPython実装コードとGlossary（専門用語の訳語固定）機能のコード、Google Cloud Translation APIでPPTXを翻訳するコードも掲載している。テキストを画像として固定させず、テキストボックスとして分離しておくことで、PPTX内の画像に埋め込まれたテキストが翻訳されないという制約を回避している。IOPaintというOSSのローカルInpaintingツールも代替手段として紹介している。

詳細

フェーズ1: マスタースライドの作成

Step 5（Adobe Expressで文字消去）の手順:

• 「生成塗りつぶし」(Generative Fill)でブラシで文字部分をなぞり「削除」を押す
• 3候補が表示され、追加候補生成のたびにクレジットが1消費
• プラン: 無料（月25回）、プレミアム（1,100円/月・月250回・月払い可能）
• IOPaint代替: pip install iopaint / iopaint start –model=lama –device=cpu –port=8080。CPU環境でも実用可。GPUがあれば –device=cuda で大幅高速化

Step 6（下地画像+テキストボックスでマスタースライド作成）の要点:

• Magic Enhance画像スライドの直後に空スライドを挿入し下地画像を貼る
• テキストボックスを隣の画像スライドに仮移動してフォント・サイズ・色・位置を合わせた後、切り取って下地スライドに貼り付け（フォントと位置が保たれる）

フェーズ2: 現地語版の生成

DeepL APIでPPTXを翻訳するPythonコードの骨格:

• translator.translate_document_from_filepath() を使用
• source_lang=“EN”, target_lang=“JA” を指定
• 10MB超のファイルはプランによっては受け付けない場合がある（高解像度画像が多い場合はファイル分割）

Glossary機能（専門用語の訳語固定）:

• translator.create_glossary() でエントリ辞書を登録
• translate_document_from_filepath() に glossary パラメータで渡す
• 例: “Magic Enhance” → “マジックエンハンス”、“Generative Fill” → “生成塗りつぶし”

Google Cloud Translation APIでのPPTX翻訳（GCPを既に使っている場合の選択肢）:

• client.translate_document() に content・mime_type・target/source_language_code を渡す
• PPTXは application/vnd.openxmlformats-officedocument.presentationml.presentation として指定
• ページ課金（$0.08/ページ）・月50万文字無料枠は適用されない
• ExcelはGCPの無料枠が適用される

フォントの縦横比について: Magic Enhanceの縦長フォントとPowerPointデフォルトの横長フォントを完全一致させるのは効率が悪いため、色・配置・余白などデザインの骨格を合わせることに集中し縦横比は横長を許容する判断が実用的。

ChatGPTの全チャット履歴もNotebookLMへ——仕様もコードもAI任せで主要AI全履歴統合が完成した話

• URL: https://zenn.dev/minipoisson/articles/chatgpt-claude-gemini-notebooklm
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Gemini・Claude・ChatGPTの3大AIの全チャット履歴をNotebookLMに統合するツールシリーズの完結編として、ChatGPT版（ChatGPT_Json2md4NotebookLM）の開発体験と実装内容を記録した記事。ChatGPTのconversations.jsonはmapping構造（ノードグラフ）でcurrent_nodeから経路を復元する必要があり、GeminiやClaude版の時系列配列より複雑。仕様書（SPEC.md）の策定をChatGPT自身に任せ、実装をCodexに任せた結果、単一スクリプトではなく責務分割された5モジュール構成＋テストコードの設計が生成された。Copilot・Claude Code・Codex三者によるコードレビューでそれぞれ異なる観点の指摘が集まった点も報告されている。

詳細

• 3版の開発体験の変遷: Gemini版はGeminiと設計+Copilotで実装、Claude版はClaude Codeに移植依頼、ChatGPT版はChatGPT（仕様）+Codex（実装）でほぼ自分で書かない体験に
• ChatGPTエクスポート形式の特徴: conversations.jsonはmapping（ノードグラフ）形式。各メッセージがノードとして親子関係で格納され、current_nodeからparentをたどって最終的な会話経路を復元する必要がある（編集・やり直しによる分岐のため）
• 他版との比較: GeminiはMyActivity.json（時系列配列）・Claude版は配列（時系列順）でどちらも分岐復元不要。ChatGPTのみglobパターンで分割ファイルを一括入力可能
• Codexが生成したモジュール構成: cli.py（CLIとファイルI/O）/ converter.py（mapping構造から会話経路復元）/ markdown.py（Markdown文字列生成）/ splitter.py（バイト数ベースのファイル分割）/ timeutils.py（epoch秒→UTC変換）+ tests/ + docs/SPEC.md
• 主な機能: current_node/parent経路復元、タイトル/create_time/update_time出力、HTMLタグのエスケープ（NotebookLMが読み飛ばさないよう）、引用・画像マーカーを可読注記に変換、デフォルト1MB分割、Python標準ライブラリのみで動作
• 使い方: python cli.py –input conversations.json –output_file ChatGPT_History.md –limit 1000000。複数ファイルはglobパターンで一括指定可能
• Copilot対応: CopilotチャットのCSVは変換スクリプト不要でNotebookLMにそのまま登録可能
• 三者三様のコードレビュー: Copilot・Claude Code・Codex自身でそれぞれ異なる観点の指摘を取得し全面対応
• 開発体験の変容: 「仕様を自分で考えない」体験が印象的。仕様の言語化からコード生成まで流れていった。動くものが出来上がりコードレビュー・テストも通ったという事実を記録

ClaudeとGeminiの全チャット履歴をNotebookLMに食わせたら、自分のAI使い分けが丸裸になった話

• URL: https://zenn.dev/minipoisson/articles/claude-gemini-notebooklm
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: ClaudeとGemini双方のチャット履歴をNotebookLMに取り込んで横断分析した実験の記録。ClaudeのデータはGDPR対応のPrivacy Portal（claude.ai/settings/privacy）からエクスポートでき、conversations.json として取得できる。Gemini版変換スクリプトの設計をほぼ踏襲してClaude向けに書き直したスクリプトをMITライセンスで公開した。両履歴を同一ノートブックに入れてNotebookLMに分析させると、「GeminiでアイデアをDB化・壁打ちし、ClaudeでそれをアーキテクトとしてCode化する」というワークフローが自分のチャット履歴から客観的に可視化された。このAI横断のユースケースはGoogle公式では実現できない領域であると著者は述べている。

詳細

Claudeチャット履歴のエクスポート方法

• claude.ai/settings/privacy にアクセスして「Export Data」からリクエスト
• リクエストからほぼ即時にダウンロードリンクのメールが届いた（一般的には数日かかると言われる）
• ZIPに含まれる conversations.json が全チャット履歴の本体

Gemini版（MyActivity.json）との主な差分:

• トップレベル構造: Geminiはオブジェクト配列、Claudeは会話オブジェクト配列
• 話者識別: Geminiはモデル/ユーザー区分、Claudeは “human”/“assistant”
• メッセージ本文: Geminiは text フィールド、Claudeは chat_messages[].text

変換スクリプトの変更点:

• 入力ファイルのデフォルト名が conversations.json
• 話者識別を “human”/“assistant” で行う
• デフォルト分割サイズを 1.5MB から 1MB に変更（1.5MBではNotebookLM取り込み失敗が稀に発生したため）

NotebookLMによる横断分析の結果

Claudeの使われ方（シニアアーキテクト・編集者として）:

• 複雑なプログラミングとアーキテクチャ設計（レガシーC#/.NETのモダン化・PythonのGAS移植など）
• 高品質な翻訳・執筆推敲（論文構成・Zenn/note記事の批判的推敲・i18n/l10nパイプライン）
• API仕様の裏取り・システム構造の比較など事実の整理と厳密な分析
• ハルシネーションを犯した場合は「存在しません」と即座に看破し構造まで冷静に分析

Geminiの使われ方（アイデアパートナー・チアリーダーとして）:

• Googleエコシステムの自動化（Gmail・GAS・NotebookLM連携・API制限回避）
• クリエイティブ・マーケティング（記事タイトル案・X投稿戦略・アイコン画像生成）
• 幅広い文脈の壁打ち（歴史・文化・AIの倫理・ユーモアなど技術に限らない議論）
• 「もっともらしい嘘」をポジティブな言葉で返してしまう傾向

translate_image ハルシネーション事件の追跡: GeminiとのチャットだけでもClaudeとのチャットだけでも全貌が把握できず、両履歴を同一ノートブックに入れることで初めて追跡可能になった。

「趣味のプログラミング」が最強である理由：ドメイン専門職×AIによる内製開発の設計思想

• URL: https://zenn.dev/minipoisson/articles/domain-expert-ai-dev-philosophy
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 製造・医療・法務等のドメイン専門職が自分の業務のためにコードを書く場合、IT業界標準のPRフロー・人間によるコードレビューは必要ないという設計思想を論じた記事。「クソコード」が生まれる構造的条件（所有権の分散・痛みが自分に返らない構造）が最初から存在しないため、PRはその防衛策として不要であり、むしろ心理的安全性を損ない職人の当事者意識を冷やすリスクの方が大きいと主張する。代わりに「職人＋AI」を軸に、コードのテキスト化とGitローカル管理（第1関門）・IDE内AIとの1対1壁打ち（第2関門）を整備し、GitHubを監視場所ではなく「知のカルテ」として使う内製化モデルを提唱している。

詳細

• クソコードが生まれる構造的条件: 所有権の分散（作る人と直す人が別）・外圧による着手強制・評価期限優先・痛みが自分に返らない構造。PRはこれへの防衛策
• ドメイン専門職の開発が「趣味」に近い理由: 所有権が明確（作った人が使い続ける）・仕様を出す人とコードを書く人が同一・品質モチベーションが内側から生まれる
• 人間レビュー不要の理由: 仕様の正解を最もよく知っているのはレビュアーではなく開発者本人。静的解析ツール（第1関門）とAIレビュー（第2関門）で大部分がカバーできる
• 人間が監査側に置かれるリスク: 「指摘できること」の目的化・好みの押し付け・心理的安全性の損壊・職人の当事者意識の冷却
• 第1関門・テキスト化とGitローカル管理: VBA/GASをテキスト化してGitで版管理。GitをAIへのコード受け渡し基盤として使う。GitHubはバックアップと次世代へのバトンであり共同監視の場所ではない
• 第2関門・IDE内AIとの1対1壁打ち: 各自のVS Code等でコードを書く瞬間にAIと壁打ち。AIは感情なく淡々と指摘し職人のプライドを傷つけない
• 属人化リスクへの回答: LLMが「このツールが何をしているか解説して」への優秀な翻訳者として機能するため、かつての「他人のコードは解読不能」問題は現代において大幅に低下
• 育成への応用: 見習い期間は先輩が大局的な相談相手に専念し、基礎的な構文等はAIに外注。独り立ち後は自分のリポジトリを持ちAIを相棒に独立独歩
• 大規模システム開発に残るもの: 認証認可・マスターデータの一元管理等インフラデータ基盤の提供と、現場職人がAIで安全に開発するためのAPI（部品）の提供
• コメント欄でのFDE（Forward Deployed Engineer）言及: Palantir等のFDEモデルを「現場生え抜きの専門職が自律型FDEとして覚醒する」形へ反転させるAI時代のDXとして議論

ExcelとAIの共存戦略――DAG×UIが理解できない現在のAIと「脱エクセル」の落とし穴

• URL: https://zenn.dev/minipoisson/articles/future-of-spreadsheet-and-ai
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: スプレッドシートが持つDAG（非循環有向グラフ）構造・視覚的レイアウト・インタラクティブUIの三層は現在のAIには統合的に理解できないが、これは現時点のAIの限界であってExcelの問題ではないと論じる。数年〜10年スパンでAIがスプレッドシートを読み解けるようになると、現在の「脱エクセルツール」への移行は逆に可読性が低くAIとの相性も悪いという逆転現象が起きる可能性を指摘する。セル結合も「現在の機械可読性のために排除するな」という論点を展開し、代わりに今やるべきことはシートの目的・設計意図・業務プロセスとの対応関係を背景情報としてテキストで明文化しておくことだとしている。スプレッドシートを直交座標系と同様の普遍的なインターフェースとして位置づけている。

詳細

スプレッドシートの三層構造とAIの理解困難性

• DAG（非循環有向グラフ）としての計算構造: セル間の依存関係ネットワーク（Excelはトポロジカル順序で計算）
• 視覚的レイアウト: 罫線・背景色・セル結合・フォントによる意味の空間的伝達
• インタラクティブなUI: 入力規則・条件付き書式による動的な状態変化

現在のAIは個々のセルの数式は解釈できるが、三層が絡み合った全体を統合理解することは困難。ただし自然言語も「機械には理解できない」とされていたのがLLMで覆ったように、スプレッドシート理解でも同様のブレイクスルーが起きる可能性が高い（業務で自然言語の次に多く使われる形式であるため各社が注力している）。

「脱エクセルツール」へのリスク警告

Excelはアルゴリズムが数式として可視化された「透明なシステム」であり、ユーザーが数式を辿って確認・修正できる。数年後にAIがスプレッドシート全体を理解できるようになると、脱エクセルを謳う専用ツールの方がExcelより可読性が低くAIとの相性も悪いという逆転が起きる。その結果、移行したデータを再度Excelに戻すという「二度手間」になるリスクがある。

セル結合を安易に排除してはいけない理由

行・列方向のセル結合は包含関係・階層構造という意味論的情報を視覚的に表現している。現在のPythonスクリプト（Pandas等）の都合で解除すると、将来のマルチモーダルAIが解釈できたはずの視覚的文脈が永久に失われる。ただしデータ交換（CSV化）や外部システム連携を前提とするシートではセル結合を避ける設計が適している場合もある。

今やるべき「背景の明文化」

• シートの目的と利用者を冒頭のセルに記述
• 数式だけでは読み取れない設計の意図をコメントやドキュメントに残す
• どの数値がどの業務プロセスに対応するかの対応関係を明記

業務別の棲み分け指針:

• 仕様が固まり反復される定型業務 → 業務システム（スケール・整合性・監査性）
• 大量データの蓄積・検索 → データベース
• 例外処理・探索的な検討 → スプレッドシート（アジリティ・透明性・柔軟性）
• システムのカバー外のニッチな業務フロー → スプレッドシート（低コストで構築・変更可）

【実録】Googleの「不足」を自分で埋め続けた記録 ── ギャップ開発が公式機能に追いつかれるサイクルと、そこから見えた法則

• URL: https://zenn.dev/minipoisson/articles/gap-filling-development
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Googleサービスの「惜しい」部分を自前のPythonスクリプトや手順で補ったところ、数か月後に同じ方向の公式機能が追加されるというサイクルが複数回起きた実録を紹介する。事例は3件で、Google GroupsのメッセージをNotebookLMに取り込む方法、GeminiチャットをMarkdownに変換してNotebookLMで活用するスクリプト、Google SlidesのAI生成テキストを編集可能にする手順などが含まれる。公式機能に追いつかれた後も、複数AIサービス横断分析といった「Google公式では原理的に対応できない領域」に独自価値が残る設計が奏功した。また、賞味期限があることを前提に最小仕様で設計することの合理性についても述べている。

詳細

3件の事例の概要

事例1: Google GroupsのメッセージをNotebookLMに取り込む（現在も未対応）

• Google Takeout でエクスポートした .mbox を Thunderbird でGmailにインポート
• Python で Gmail API を使って差分取得・Gemini APIで要約→Google Docsに追記
• Google Docsをソースとして NotebookLM のノートブックに登録
• 現在もスクリプト稼働中（公式対応はされていない）

事例2: GeminiチャットをNotebookLMで活用するスクリプト（公式連携後も一部価値が残存）

• Google Takeout でエクスポートした MyActivity.json を Markdown に変換するOSSスクリプト Gemini_Json2md4NotebookLM を作成・公開
• 処理内容：HTMLタグ除去・Markdown整形・指定サイズ（デフォルト1.5MB）での自動分割・差分更新
• 公開後に2桁多いアクセスが継続し、同じ「惜しさ」を感じていたユーザーの多さを示した
• その後Gemini公式のNotebookLM連携が強化されたが、ClaudeやChatGPTなど他AI履歴には非対応のまま

事例3: Google SlidesのMagic Enhance生成テキストを編集可能にする手順（現在は公式が対応）

• PPTX書き出し → PNG一括エクスポート → Adobe Expressで文字消去 → テキストボックスで載せ直し
• 記事公開後ほどなく公式の編集可能版生成機能がロールアウト

考察の要点:

• Googleが「不完全な状態でリリース」するのはフィードバック収集のため、ユーザーの自作ツールが需要シグナルになる
• 公式に代替されにくい独自価値を持たせるには「公式の延長線上だが公式が踏み込めない領域」を意識する
• 賞味期限があるツールは最小仕様で設計することが合理的。標準ライブラリのみで完結させた事例2がその実践
• コードが不要になっても「なぜその問題が起きていたか」という記録は参照資料として残る

【実録】GeminiはGoogle自社サービスの夢を見るか？　―― ハルシネーションの実例・傾向・対策

• URL: https://zenn.dev/minipoisson/articles/gemini-hallucination-google-services
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GeminiがGoogle自社サービスについてハルシネーションを起こした実例3件を、実際のチャットログとともに記録・分析した記事。translate_image という存在しないTranslation APIメソッドを自信満々に生成し続けた件、GASエディタでTypeScriptが直接使えると誤案内した件、NotebookLMのグループ共有が可能と誤案内した件を扱う。命名規則のパターン補完（translate_text/translate_documentがあれば translate_image もあるはず）や、WebUIとAPIの混同が主因として考察されている。業務でAIを使う際の実践的な対策として、公式ドキュメントURLの要求・他AIによるクロスチェック・時間軸を明示したプロンプト・「できない理由」を先に聞く手法なども具体的に紹介している。

詳細

実例1: translate_image ハルシネーション（最も根深い事例）

Geminiが提示したコードの問題箇所:

• image_payload キーが存在しない
• client.translate_image() メソッドが存在しない
• response.translated_image フィールドが存在しない

Geminiの誤りの上塗りパターン:

1. pip install –upgrade でライブラリ更新を提案（根本原因ではない）
2. v3beta1 への変更を提案（効果なし）
3. Pylanceの型チェックを # type: ignore で無視するよう提案

GitHub Copilotは同じ質問に対して「translate_image は存在しないメソッド」と即座に正確に回答。

根深い理由の分析:

• パターン補完: translate_text・translate_document が実在するため translate_image も存在すると推論
• WebUI・API混同: Google翻訳WebUIの画像翻訳は内部エンジン使用でありAPIとして非公開
• 用語衝突: OpenCVなどで translate_image（画像の平行移動）という関数名が学習データに大量存在

実例2: GASでTypeScript直接使用の誤案内

• 事実: 2026年時点でも標準GASエディタで .ts 直接実行は不可。clasp が必要
• Geminiの対応: 「お客様のアカウントが異常な状態」として環境のせいにした

実例3: NotebookLMのグループ共有誤案内

• 事実: 個人版NotebookLMでは @googlegroups.com アドレスは非対応（Enterprise版のみ対応）
• Geminiがこの件では誤りを認めた理由: 即時フィードバックが得られ、検証が単純だったため

ハルシネーションのレッドフラグ:

• 「〜は存在はします。ただし〜」という構造（存在を認めながらユーザー側に帰責）
• バージョン番号や「特定リージョン限定」などの過剰な具体性（ワーキングメモリを占有して批判を後回しにさせる）
• 「お客様のアカウント」「環境の問題」への転嫁
• 全面肯定のあとに来る「微調整アドバイス」

対策:

• 公式ドキュメントのURLを要求して実際にアクセス確認
• 他のAI（Claude、GitHub Copilot、Perplexity）でクロスチェック
• Pylanceなどの型チェックを事前検証に活用
• 「2026年現在、一般公開されているAPIの仕様に基づいて」と時間軸を明示
• 「できない理由・制約を先に教えて」と問う

Tesseract 5 × OpenCV で作る、閉鎖環境向け OCR 文書検証ツール

• URL: https://zenn.dev/minipoisson/articles/ocr-file-verification-tool
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 医療・行政・法務などインターネット接続不可の閉鎖環境において、大量紙文書の誤混入を自動検証するC# + Tesseract 5 + OpenCVのOCRツール ocrFileVeriProc の設計と実装を紹介する。従来のトリプルチェック体制や1枚ずつカメラにかざす既存システムが抱えていた「疲労・2枚重なり検知漏れ・膨大な作業時間」という課題を、ソーター付きスキャナ一括スキャン→OCR自動判定→フォルダ仕分け→差異確認のみ人間が対処するフローで解決している。閉鎖環境での長期安定性を優先して最新の.NET 10ではなく.NET Framework 4.8を選択したことや、日本語モードを意図的に無効にして英数字限定で照合精度を担保した戦略など、運用制約に即した技術選定の判断基準を詳しく解説している。

詳細

背景と課題

多数顧客向け文書の並行発行現場で「誤混入」（別人宛て文書が混入）の防止が課題。従来の対策の問題:

• 3人体制のトリプルチェック: 疲労・慣れによるミスをゼロにできない
• 1枚ずつカメラにかざす既存システム: 膨大な作業時間・2枚重なって捲れた場合の検知漏れ
• クラウドOCRサービスが使えない（データが閉鎖環境にある）

解決フロー:

1. ソーター付きスキャナで文書を一括スキャン
2. OCRアプリが画像内のID番号や文書種別コードを読み取る
3. 業務システムから取得した正しい識別子との一致を判定してフォルダを自動仕分け
4. 不一致の可能性がある画像のみ人間が確認

技術選定の判断

.NET Framework 4.8 × C# 8.0 を選択した理由:

• Windows 11のOSコンポーネントの一部として扱われ、OSのサポート期限まで利用可能
• 更新が容易ではない閉鎖環境では最新フレームワークより長期安定性を優先
• .NET 10等は閉鎖環境でのランタイム更新が課題になる

OCRエンジン・画像処理:

• Tesseract 5: 日本語・英数字の認識精度が旧バージョンより大幅向上、処理がオフラインで完結
• OpenCvSharp: 傾き補正・二値化などOCR精度を左右する前処理を高速に行う

実装のポイント

並列処理（TPL / Task Parallel Library）:

• Parallel.ForEach を使用
• MaxDegreeOfParallelism = Math.Max(1, Environment.ProcessorCount - 1)（1コア分空けてUIレスポンスを確保）

ファイルロック管理:

• Bitmap を直接OCRにかけず、using 句でスコープを管理してメモリ上で Mat に変換
• bmp のスコープを抜けた瞬間にファイルロックが解放されるため File.Move・File.Delete が安全に実行できる

英数字限定戦略（「あえて日本語を扱わない」）:

• Tesseractの日本語モードを有効にすると「1」を「①」「一」と誤読するリスクが高まる
• 判定対象をIDやコード類に絞り、英数字のみの学習データを使用して照合信頼性を担保

UI/UX設計:

• 判定ルール設定: 「行内に複数を書けばAND、行を分ければOR」という直感的なUI
• Windows Explorerとの協調: アプリ内に高度な画像ビューアを作り込まず、Explorerでフォルダを開いて整理させることでアプリ自体を軽量に保つ

本番運用は諸事情により見送りとなったが、閉鎖環境での試行錯誤のプロセスをOSSとして公開。

PPTXの翻訳をAIチャットで完結させる：pptx_yaml_excelの使い方

• URL: https://zenn.dev/minipoisson/articles/pptx-yaml-excel-translation-workflow
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: PowerPointのテキストをYAML形式で一括抽出し、AIチャットで翻訳して書き戻すExcel VBAツール pptx_yaml_excel の使い方を解説する。xlsm ファイルを開くだけでインストール不要で動き、特定の翻訳エンジンへの依存もなく、ChatGPT・Gemini・Claude など任意のAIチャットと組み合わせて使える。テキストを sNN.シェイプ名.pNN というキー形式のYAMLに変換することで、AIに渡しやすい形にしている。テーブルのセルも .rNNcNN 形式でエンコードされ、スライドへの書き戻し時にキーで対応付ける仕組みになっている。

詳細

ワークフローの流れ

1. pptx_yaml_i18n.xlsm を開いてマクロを有効化（言語設定は D1 セルのドロップダウンで27言語対応）
2. 原本PowerPointを指定して抽出ボタンを押すと YAML ファイルが生成される
3. YAML ファイルをAIチャットに添付して翻訳を依頼し、ファイル名指定でダウンロード
4. 翻訳済みYAMLを指定してベースPPTXを選び「反映済みPowerPointを作成する」を押す

YAMLキーの形式: s01.Title.p00（スライド番号.シェイプ名.段落番号）。テーブルセルは .r00c00 形式。

実行後の報告内容:

• 正常に反映されたキーの数
• PowerPointにのみ存在するキー（YAML側に対応翻訳がなかった箇所）
• YAMLにのみ存在するキー（PowerPoint側にシェイプが見つからなかった箇所）
• 不正な形式のYAML行

スライド構造（シェイプの追加・削除・名称変更）を変えた場合はYAMLの再抽出が必要。このツール自体がxlsm_devkitを使って開発されており、xlsm_devkitの実践事例でもある。

なぜExcel/VBAは軽視されるのか：技術ヒエラルキーと現場・管理の非対称性

• URL: https://zenn.dev/minipoisson/articles/psychology-of-technical-hierarchy
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: なぜExcel/VBAという技術は技術コミュニティで軽視されるのかを、情報処理技術者の心理的背景と管理・現場という組織上の立場の非対称性から分析した記事。技術の種類（何を使ったか）によってエンジニアの価値が品定めされる目に見えないヒエラルキーが存在し、ChatGPT/GeminiなどのAIもそのバイアスを反映した回答を返すことがある。現場でExcel/VBAが選ばれるのは技術力の問題ではなく「現場で使える技術がそれに限られている」という立場の問題であること、そして管理部門がドメイン知識への強い心理的負荷（ドメイン恐怖症）を持つ結果として「自分たちしか使わない技術」の方を価値が高いと位置づけたい動機が生まれる構造を明らかにしている。対立の解消策として「ハイブリッドな立ち位置の公認」と「解決の質で語り合う共通言語の構築」を提案している。

詳細

技術ヒエラルキーの実態

クラウド・分散DB・Rustは「高尚」とされ、Excel/VBAは「古臭い・非エンジニアの道具」として扱われる。極端なケースとして、マクロ付きExcelをRedmine等の課題管理システムで網羅的に管理していても「バージョン管理できていないはず」と決めつけられたり、「データや数式と一体になったVBAコードだけをgitで管理すべき」という実情から乖離した提案をされたりする。ChatGPT・Geminiも技術コミュニティへの書き込みを学習しているため、このバイアスを反映した回答を返すことがある。

ドメイン恐怖症という構造

情報処理技術者は医師・弁護士と違い名称独占・業務独占がなく、現場部門にも技術力の高い人が存在する。そういった人はドメイン知識にも精通しており、ドメイン知識を持たない専門家には太刀打ちできない強みを持つ。情報システム部門は現場の切羽詰まった場面でドメイン知識の理解を求められがちで、それが強い心理的負荷（ドメイン恐怖症）を生む。結果として「自分たちしか使わない技術の方が価値が高い」という方向の技術コミュニティへの書き込みが増え、AIもそれを学習する。

管理部門の合理と現場部門の合理

管理部門: セキュリティ・ガバナンスを守る責任がある。技術に詳しい現場担当者が去ると業務継続が困難になり「属人化リスク」として現れる。一部の部門にだけ特権を与えることもできない。 現場部門: 業務システムの機能不足・改修却下という状況下で自力解決を選ぶのは合理的。PDCAサイクルが部門内に閉じると体感速度が桁で変わる経験をすると「二度と戻れなくなる」。「技術の属人化」と「業務の属人化」という言葉の定義のズレが対話を困難にしている。

「技術力ではなく立ち位置が技術の種類を決めている」という核心

ExcelやVBAが使われるのは現場部門で使える技術がそれに限定されているから。クラウド・Rustが高尚に見えるのは現場部門では使われず専門家だけが触れる技術だから。著者自身はC#画像処理・Python分析・AI活用という「高尚」な技術スタックとExcel/VBAハックの両方を経験しているため、この壁が技術力ではなく立場の違いに起因していると見えている。

解決策:

• 「ハイブリッドな立ち位置」の公認: 現場の技術者に管理部門への兼務・技術アドバイザーの公的役割を付与
• 「解決の質」で語り合う: 「Excelだからダメ」ではなく「そのツールがいかに業務継続性を担保しているか」を共通言語にする
• 管理部門は禁止ではなく「安全に・属人化させずに運用し続ける方法」の技術的サポートを提示する

その「技術的負債」の定義は誰のため？：現場の改善を止める「すれ違い」をほどく

• URL: https://zenn.dev/minipoisson/articles/technical-debt-deception
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 「技術的負債」という言葉が情報システム部門と現場部門の間で異なる基準でカウントされており、それが組織内の不公平な対立を生んでいることを指摘する。現場がExcel/VBAで業務を改善すると情報システム部門はそれを「保守リスクという負債」としてカウントするが、現場にとっては業務システムの機能不足という「確定した負債を返した」行為であり、この基準の非対称性が対立を生む。代替案なしに「VBAは負債だから禁止」とするのは、不確実な将来リスクを回避するために他部門に確定したコストを強制することであり、負債の付け替えに過ぎないと論じる。解決策として「管理された自由」（EUCへのルールと支援のセット）と現場プロトタイプを動く仕様書として敬意を払うことを提案している。

詳細

技術的負債のカウント基準の非対称性

情報システム部門のカウント:

• 業務システムの機能不足（要望未充足）→ 「技術的負債としてカウントしない」（まだシステムがない）
• 機能不足で現場が毎日1〜2時間無駄にしてきた確定的損失 → 「カウントしない」（システムの話ではない）
• 現場がExcel/VBAで開発した機能の将来保守リスク → 「技術的負債としてカウントする」

この構造が「自部門の不都合だけをカウントする不公平な理屈建て」として現場に受け取られる。

負債の付け替えという問題

「統制外EUCの排除に成功した」裏で現場の赤字が膨らんでいれば、組織全体では質の悪い負債の付け替えが起きている。本来の技術的負債管理は「どの負債を抱えるのが組織にとって最も低コストか」という経営判断であるべき。

選択肢の比較:

• 選択肢A: VBAを許容し将来の保守リスクという負債を負う
• 選択肢B: VBAを禁止し毎日の業務遅延とモチベーション低下という負債を負う
• 選択肢C: 必要機能を業務システムに実装するリソースを調達コストとして負う

機会損失という見落とされた負債: 現場が毎日貴重な労働をドブに捨てている状態は「人的資本の浪費」という高い利子を伴う負債。モチベーション低下は複利で組織を蝕む。

3つの解決策

ステップ1「負債の総量で会話する」:

• 現場は「機能がないことで年間〇〇時間の工数が失われている」とコストで訴える
• 情報システム部門は「その機能を業務システムに実装するコストと優先順位」を透明化する

ステップ2「EUCに管理された自由という低利の融資をする」:

• 「放任」でも「全面禁止」でもなく、ルールと支援をセットにした枠組みを作る

ステップ3「現場のプロトタイプを動く仕様書として敬意を払う」:

• 現場のExcel/VBAは「最も優れた動く仕様書」であり業務フローへの適合も実証済み
• 将来的な正規実装へのインプットとして活用する

業務Excelに実践投入して見えたもの ─ xlsm_devkit の完成度を上げる

• URL: https://zenn.dev/minipoisson/articles/xlsm-devkit-production-hardening
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: xlsm_devkitを8000セルのアルゴリズムが実装された実業務Excelに本格投入した際に顕在化した問題群と、その改善を記録した記事。PoC段階では現れなかった速度（Application.ScreenUpdating等3行の欠落、O(n²)の文字列連結）・roundtrip信頼性（数値と表示形式NumFmtの不可分性、セミコロンエスケープ、"-“番兵値衝突、先頭末尾スペース消失）・DEV/Releaseワークフロー自動化という3つのテーマが対象。「export→import→exportのMarkdown完全一致」をリリース条件に設定することで双方向ワークフローの信頼性を担保した。AI（主にCodex）が実装を担ったが、VBAの短絡評価なし仕様など言語固有の罠はAIが見落とし人間が発見するケースが複数あった。

詳細

• 速度問題1・importが遅い: Application.ScreenUpdating=False/EnableEvents=False/Calculation=xlCalculationManualの3行が抜けていた。小規模PoCでは気づかず業務Excelで発覚。AI主体開発では規模依存の定型コードが抜けやすい
• 速度問題2・exportが遅い（O(n²)文字列連結）: str=str & newPartの連結が8000セル規模で問題化。DevkitStringBuilder UDT（配列に追記→最後にJoinで一括連結O(n)）を実装して対処。体感上は進捗表示（StatusBarへの表示）の方が効果が大きかった
• roundtrip問題1・数値と表示形式の不可分: Excelは日時を数値で保持するためNumFmtなしでは往復で値が壊れる。NumFmtを扱う機能を追加して対処
• roundtrip問題2・セミコロンエスケープ: Styleのセミコロン区切りと表示形式文字列（例: #,##0.00;[Red]-#,##0.00）内のセミコロンが衝突。スタイル値内のセミコロンを;にエスケープし、ParseStyleTokensで対処
• roundtrip問題3・”-“番兵値とリテラルの衝突: 空セルの番兵”-“とセル値の文字列”-“を区別できなかった。リテラルは-にエスケープして出力し復元
• roundtrip問題4・先頭末尾スペースの消失: Trim()をTrimMDTableField（先頭末尾の1スペースのみ除去）に置換
• リリース条件: export→import→exportで生成されるMarkdownが完全一致することを必ず確認してからリリース
• エラー値セルでのクラッシュ: rng.ValueでエラーセルはVBAランタイムエラー。IsError()でチェックしrng.TextをフォールバックにするがVBAはAND式の短絡評価なし→AIがNot IsError()をAND内の式Aに書いて式B内でエラーが発生する問題があった
• プロテクトシート混在: import開始前にAbortIfProtectedImportSheetsで全対象シートの保護状態を確認し保護シートがあれば中止
• import失敗時の状態復元: エラーでもApplication.ScreenUpdating等を必ず復元するエラーハンドラーを整備
• CallInitDevMode/CallSaveAsRelease: DEVコピー作成と配布用クリーンファイル生成の自動化でモジュール削除忘れリスクを解消

シート変更をAIに追従させる ─ xlsm_devkit 新機能と「脱Excel」再考

• URL: https://zenn.dev/minipoisson/articles/xlsm-devkit-sheet-change-to-ai
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: xlsm_devkitに行・列の挿入削除（InsertDelete）とセル範囲の移動（Move）をAIに追従させる新機能を追加した記事。8000セルのアルゴリズムが実装された業務ExcelをAI（CLAUDE CODE/CODEX/Antigravity）が的確に読み解けたという体験から、VBAコードのアドレス参照追従という長年の課題もAIで解決できると判断して実装した。InsertDeleteはダイアログで操作指定後に変更前後のシートマップとVBAコード更新プロンプトを自動生成し、Moveはマクロ記録機能でユーザーの移動操作を捕捉してプロンプトを生成する。MoveのVBAランタイムリセット問題はWindowsレジストリに中間状態を保存することで回避した。

詳細

• 解決した課題: 行/列の挿入削除やセル範囲移動の際にVBAのアドレス参照（Range(“E5”)・Cells(5,3)等）が自動追従しない問題。手動修正では参照箇所が多いと見落としが発生
• AIによる8000セルのExcel読解: CLAUDE CODE（Sonnet 4.6）・CODEX（GPT-5.5）・Google Antigravity（Gemini 3.1 Pro）がいずれも的確にアルゴリズムを読み解き機能を説明。回答時間はCLAUDE CODE 10分、CODEX/Antigravity 1分程度
• 脱Excel言説への反論: AIが複雑なExcelを読み解いて誰でも理解できるよう解説できるなら、Excelの「属人性」を根拠とする脱Excel移行の主張は前提が崩れている
• InsertDeleteの操作フロー: フォームで操作内容指定→ExcelへのD列1列挿入等を実行→変更前後のシートマップ保存→AI向けプロンプト自動生成→AIチャットに貼り付け→src/*.basを修正→インポート
• Moveの設計方針: セル範囲の移動はダイアログ指定よりユーザーが直接操作する方が確実。Excel標準のマクロ記録機能で操作を捕捉し記録されたコードを解析してプロンプト生成
• MoveのVBAランタイムリセット問題: VBA実行中にマクロ記録を開始するとVBAランタイムがリセットされ変数の状態が消滅。対処としてWindowsレジストリに中間状態を保存し記録終了後に復元
• 生成プロンプトの内容: 操作内容の説明・String形式/Numeric形式/Dynamic形式のアドレス参照形式を列挙・変更前後のシートマップへの@パス参照・コード外の参照や要確認事項のリスト要求
• Move後のマクロモジュール警告: 記録マクロ（Module2等）がVBAプロジェクトに残るためプロンプト末尾に削除促進警告を自動付与。AIがVS Code上のモジュールやExcel COM経由での削除まで対応するケースも
• xlsm_devkitの自己参照的発展: PowerPoint翻訳ツールから生まれたxlsm_devkit→xlsm_devkit自身を使ってオプション機能を開発→オプション機能が本体をさらに強化というサイクル

シートとコードをAIに渡す：「実態はアプリ」のExcel開発ツール xlsm_devkit

• URL: https://zenn.dev/minipoisson/articles/xlsm-devkit-sheet-code-to-ai
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: ExcelマクロファイルをAIと共同開発するためのVBAツール xlsm_devkit を紹介する。このツールの核はシート全体の構造（セル値・数式・図形・スタイル）をMarkdownとして書き出す ExportAllSheetMapsToMD 機能で、VBAコードと合わせてAIに渡すことで「このシートの構造を踏まえてコードを書いて」という依頼が成立する。既存のVBAコード管理ツールはコードしか扱えないが、xlsm_devkit はシートとコードの両方をAIに渡せる点が本質的な差異となっている。.bas ファイル1本でインポートでき、外部ツール不要で動作する。

詳細

xlsm_devkitが提供する3つのマクロ

• ExportAllModules: 全VBAモジュールを src/*.bas（UTF-8）として書き出す
• ImportAllModules: src/*.bas をVBAプロジェクトに読み込む（xlsm_devkit自身はスキップ）
• ExportAllSheetMapsToMD: 全シートの構造を sheet/*.md として書き出す

ExportAllSheetMapsToMD が出力する情報

• セルのアドレス・名前定義・値・数式・スタイル（背景色・文字色・文字サイズ・入力規則）
• 図形の位置・名前・テキスト・数式参照・OnAction（クリック時に呼ぶ処理名）・スタイル
• 出力しない情報：罫線・列幅・行高・結合状態・フォント名（AI理解に不要と判断）

色はCSSに近い #rrggbb 形式で出力（VBAのBGR Long値を変換）。AIが色の意味を文脈から推測しやすくなる。

実際の効果として、pptx_yaml_excel 開発時にシートマップを出力したところ、Geminiが生成した「Very Hidden シートとキャッシュVBAコード」という複雑な設計を「Visible シート + MATCH/INDEX数式」へ抜本的に再設計できた。シート構造が可視化されることで、冗長なコードが不要になる方向への設計改善が自然に起きる。

技術的なポイントとして ImportAllModules の自己スキップ機能があり、実行中のモジュールが自身を上書きできない制約を回避している。

マクロなしの業務帳票に踏み込む ─ xlsm_devkit の .xlsx 対応と、AI による数式査読

• URL: https://zenn.dev/minipoisson/articles/xlsm-devkit-xlsx-support
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: xlsm_devkitをマクロなしExcel（.xlsx）に対応させ、複雑な数式の塊である業務帳票を開発対象にした実装記録。.xlsxの場合、SaveCopyAsでVBAプロジェクトがコピーに含まれないという.xlsmとの挙動差異を実際に動かして初めて発見し、一時コピーにxlsm_devkit.basを再インポートする分岐を追加した。帳票適用では大量セル結合による8〜15分の処理遅延・Pictureオブジェクトへのラベル代入エラー・結合セルの.Locked設定エラーなど多数の課題が顕在化し、それぞれ選択インポート（xlsm_devkit.ini）・HasTextFrameチェック・MergeArea.Lockedへの変更で対処した。AIへの「実装完了」報告が仮説にすぎず、人間による動作確認が不可欠だという教訓も記されている。

詳細

• .xlsxと.xlsmの挙動差: SaveCopyAsは元の形式を保つため.xlsxのコピーにはVBAが含まれない。対処: 一時コピーに追加モジュールをインポート後、src/xlsm_devkit.basを再度インポートして.xlsmとして保存
• 課題1・大量セル結合による遅延（8〜15分）: 結合解除→属性書込→再結合の流れが帳票では致命的。選択インポート（xlsm_devkit.ini）のmerge=0で結合構造はそのまま、セル値・数式のみ更新するよう対処→ほぼ一瞬に短縮
• 課題2・Picture型図形へのラベル代入（Err 438）: shp.HasTextFrameで確認しテキストフレームを持たない図形へのラベル適用をスキップ
• 課題3・結合セルのLocked設定（Err 1004）: 結合領域に属する単一セルへのrng.Locked代入が不可。rng.MergeArea.Locked = Falseで結合領域全体を対象にすることで解決。unlocked=0が既定（オプトイン安全装置）
• 課題4・1セルの失敗で全体が中断: Bold/Italic/Strike/Wrap/UnlockedのトークンをOn Error Resume Nextで囲み、失敗は診断ログに記録して続行
• merge=0の副作用・ドリフト: ClearFormatsを含む重い処理を省略したことで「Markdownからトークンを削除=既定に戻す」という不変条件が破られ、Excelに残った属性がそのまま残るドリフトが発生。対処: インポート時に対象フラグが有効なら該当属性を既定値へリセットしてからトークン処理（v1.11.0）、さらに空セルでもリセットが走るようにしread-before-writeで余計なCOM書込を抑制（v1.12.0）
• AI依頼の教訓: AIの「実装できました」報告はまだ検証されていない仮説。「コードがそう書いてある」と「実物でそう動く」の間には隔たりがあり、人間側の確認と背景知識が必要
• Application.StatusBarへのDoEvents追加: 1000セルごとのDoEventsでは進捗が見えないケースがあり、.StatusBar直後にDoEventsを追加（AI報告を信じて確認を怠った失敗の事例として記録）

gh skill でAIエージェントにAgent Skills を取り込む・公開する方法

• URL: https://zenn.dev/mkj/articles/7abf3e4f48bfc4
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 2026年4月16日にGitHub CLI v2.90.0でパブリックプレビューとして追加されたgh skillコマンドを使い、Agent Skillsをインストール・公開する手順を実機ログ付きで紹介した記事だ。install時にTree SHAを記録して改ざん検知する仕組みを持ち、claude-code/codex/github-copilotなど30種以上のエージェントを–agentオプションで指定できる。publish側ではGitHub Releaseとしてスキルを配布し、skill名・ディレクトリ名の一致やフロントマター要件（allowed-toolsは文字列で書く等）を–dry-runで事前検証できる。GitHubを普段使いしているチームでスキルを共有する際の標準的な選択肢として位置付けられている。

詳細

gh skillのサブコマンド6つ

• install: 公開リポからスキルを取り込む
• preview: インストール前にSKILL.mdとファイル一覧を表示
• list: インストール済みスキルを表示
• search: GitHub Code Search経由でスキルを横断検索（–ownerで絞り込み可）
• update: gitの最新コミットに片方向同期（ローカル編集は上書きされる）
• publish: ローカルリポのスキルを検証してGitHub Releaseとして配布

インストール時の挙動

• –agent claude-codeを指定すると/.claude/skills以下に配置
• –scope userでグローバル運用可能
• privateリポジトリもgh authでrepoスコープがあれば取り込み可能（searchには出ない）
• Tree SHA記録による改ざん検知あり

publishの検証項目（–dry-run）

• skill名がagentskills.ioの命名ルール（小文字+ハイフン）に合致するか
• skill名とディレクトリ名が一致するか
• 必須フロントマター（name, description）の有無
• allowed-toolsが文字列か（配列はNG）
• install時のmetadata.github-*が残っていないか

SKILL.mdのディレクトリ発見規約

• skills/*/SKILL.md
• skills/{scope}/*/SKILL.md
• */SKILL.md（ルート直下）
• plugins/{scope}/skills/*/SKILL.md

対抗実装npx skills（Vercel Labs、MIT）はGitLabにも対応するが、記事筆者はgh統合の利便性からgh skillを推奨

社内向けAIアシスタントを3か月間試験運用してみた

• URL: https://zenn.dev/mkj/articles/87c3ce556cde90
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 松尾研究所が2026年2〜4月にかけてSlack上でOpenClawライクな社内AIアシスタント（mbot）を3プロジェクトで試験運用した結果をまとめた記事だ。nanobotをベースにSlack対応・Notion/GitHub連携・スケジュール機能・コンテナ対応を追加して開発し、Claude Code/Codex CLI/ローカルLLMをバックエンドに切り替えできる設計にしている。8名のアンケートでは業務効率化貢献度7以上が100%、週30分以上の時間短縮が75%、全社導入を強く推奨が50%という結果だった。一方でセットアップの複雑さ・コスト増加・データソース非透明性といった課題も明確になっている。

詳細

mbot（社内AI）の概要

• ベース: nanobot（当時OpenClaw系でシンプルなOSS）をフォークして社内要件を追加
• バックエンド: Claude Code / Codex CLI / ローカルLLMを切り替え可能
• 機能: Slackメンション→スレッド単位継続会話 / チャンネルごとのシステムプロンプト注入 / GitHub Apps認証 / スケジュール機能 / コンテナ隔離

ワークスペース設計（AIツール非依存化）

• AGENTS.md（実体）とCLAUDE.md/AGENTS.md/MEMORY.mdをシンボリックリンクで吸収
• スキルディレクトリも同様にシンボリックリンク（.claude/skills, .agents/skills）

活用事例

• 週報作成: Notion/GitHub Projectsを横断してスキルを一度チューニング後に自律的に収集・整形
• 論文・テックニュース毎朝自動配信: PJT情報を踏まえたパーソナライズアドバイス付き
• PRレビュー: Claude Code/Codex CLI/Gemini CLIによるマルチエージェントレビュースキルを構築
• その他: Notion調査・スライド作成・アイデア出し

アンケート結果（8名/3PJT）

• コードレビュー・資料検索での利用が85.7%で最多
• 業務効率化貢献度7以上が100%、9以上が62.5%
• 週30分以上時間短縮が75%、1時間以上が25%
• 全社導入を強く推奨（5）が50%、4以上で62.5%

課題と利用者コメント

• Notionの全件精査など長時間タスクでタイムアウト発生（逐次ログで対応）
• データソースが不透明でbotを使わなかった利用者がいた（UI説明チューニングが必要）
• 出典リンクの明示が不足
• コスト: 1PJTあたり約1〜2万円/月（利用頻度・人数で増加）
• セットアップ: クラウド環境/Slack Bot/Notion/GitHub Apps設定が多岐にわたり複雑

AIで加速するプロダクトの変化を、開発チームの外に届ける仕組みづくり

• URL: https://zenn.dev/nstock/articles/ui-change-notifier
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Nstock では AI 活用によって 1 日あたり約 20 件の PR がマージされるペースになり、CS・Sales チームがプロダクトの変化を把握しきれない問題が生じた。解決策として Claude Code Actions を使い、一定期間にマージされた PR の差分を自動で読み取り、CS・Sales が知るべき UI 変更だけを抽出して Slack へ通知する仕組みを構築した。技術用語を使わずに画面・機能ごとにまとめたメッセージを生成するプロンプトを設計し、Structured Output でフォーマットを固定している。アンケートでは回答者全員が週 1 以上確認し、AI 検知・要約の精度は 8.8/10 と高評価を得た。

詳細

課題の背景:

• Coding Agent の普及で PR マージ数が月 200 件（2025 年 6〜12 月）から月 300〜400 件（2026 年 1〜4 月）に増加
• デザイナー等の非エンジニアも PR を作成するようになり、開発速度がさらに加速
• 大きな機能変更は週次スプリントレビューで共有しているが、細かい UI 変更の共有は個人裁量に委ねられており、CS・Sales が把握しきれなかった

仕組みの構成:

• GitHub Actions の Cron トリガーで定時実行
• 前回ワークフロー成功時から現在までの差分を対象に取得
• Claude Code Actions（anthropics/claude-code-action）で PR 差分を解析
• モデル: claude-opus-4-6-v1（Amazon Bedrock 経由）
• Structured Output で {“changes”: [{“feature”: “画面名”, “details”: [“変更内容”]}]} の形式を強制
• Slack の専用チャンネルへ画面・機能ごとに通知

プロンプト設計のポイント:

• 対象: UI 変更・メールテンプレート変更・フロントエンドで使われる API レスポンス変更
• 対象外: ロジック・リファクタリング・軽微なスタイル調整・型定義のみの変更
• 記述ルール: 技術用語禁止、ユーザー目線で「何がどう変わったか」を書く、1 items あたり 120 文字以内

アンケート結果（一定期間の運用後）:

• 閲覧頻度: 全員が週 1 以上、62.5% は毎日確認
• 課題解決度: 7.4/10、AI 精度: 8.8/10、推奨度: 7.8/10
• 今後: 変更差分のスクリーンショット添付などの改善を検討中

週次リセットで消えるAIトークンを無駄にしない — token-burn を作った話

• URL: https://zenn.dev/owayo/articles/02a0a061697fa3
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: AIコーディングアシスタントのトークンが週次リセットで未使用のまま消滅する問題を解決するため、Rust製CLIツール「token-burn」が作られた。リセット直前の残量を検知して複数リポジトリへプロンプトを並列実行し、リセット時刻になると全プロセスを自動終了する設計になっている。tmuxによるペイン分割でリアルタイムに進捗を監視でき、Claude CodeおよびCodex CLIの両方に対応している。失敗プロバイダーを冷却時間で後回しにするクールダウン機能を備え、複数エージェントを自動フォールバックしながら安定的に活用できる点が実用性を高めている。設定ファイルで並列数や対象ディレクトリ・プロンプトを柔軟にカスタマイズでき、公開リポジトリを優先して処理する機能も持つ。

詳細

token-burn はリセット直前のトークンを有効活用するRust製CLIツール。

主な機能:

• Claude Code（木曜20:00 JST）と Codex CLI（火曜12:00 JST）のリセット時刻を設定ファイルで管理し、最も近いエージェントを自動選択する
• tmuxのペイン分割で最大4並列（parallelism = 4）のワーカーを起動し、各ワーカーの出力をリアルタイム確認可能
• デッドライン制御は二段階: ソフトストップ（stopマーカー作成でタスク完了後に停止）、ハードキル（Ctrl-Cで即時kill-session）
• Claude CodeのストリームJSONを format-stream サブコマンドで可読形式に変換し、思考過程・ツール呼び出し・コスト情報を表示
• gh CLIと連携して公開リポジトリを優先処理できる
• 実行ログをYYYYMMDD_HHMMSS_形式で保存し、デフォルト7日で自動削除
• 設定例として depup との組み合わせにより週次でライブラリメンテナンスを自動化できる
• Homebrewでインストール可能（brew install owayo/token-burn/token-burn）

もう「wip」コミットを作らない！AI自動フォールバックでコミットメッセージを生成するgit-scを作った

• URL: https://zenn.dev/owayo/articles/09890771d30b3c
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GeminiやCodex CLI、Claude Codeなど複数のAIプロバイダーに対応し自動フォールバックするコミットメッセージ生成ツール「git-sc」がRustで開発・公開された。プロバイダーがレート制限などで失敗すると次のプロバイダーに自動切り替えし、失敗したプロバイダーを一定時間（デフォルト1時間）優先度を下げるスマートクールダウン機能も備えている。過去のコミット履歴からConventional CommitsやEmoji形式などのフォーマットを自動検出し、プロジェクトの慣習に合ったメッセージを生成する。追加API費用を払わず既存の定額サービスの中だけでコミットメッセージ生成を完結させたいというニーズに応えるツールである。

詳細

git-sc（git smart commit）はAIを使ったコミットメッセージ自動生成ツール。Rust実装でシングルバイナリ、GitHub Releasesから各プラットフォーム向けのバイナリを配布。

主な特徴:

• 対応プロバイダー: Gemini CLI、Codex CLI、Claude Code を設定した優先順序で試行
• スマートクールダウン: 失敗したプロバイダーを設定可能な時間（デフォルト60分、0で無効化）だけ後回し。provider_cooldown_minutes で調整可能
• フォーマット自動検出: 過去5件のコミットからConventional Commits、ブラケット形式、絵文字形式、プレーン形式を自動判断
• URLベースルール: [[prefix_rules]] でリポジトリのリモートURLに基づく正規表現マッチングでフォーマットを強制指定可能
• –reword N: N個前のコミットメッセージをAIで再生成（内部でgit rebaseを使用）
• –squash origin/main -y: ブランチのコミットを1つにまとめてメッセージを生成
• –amend: 直前のコミットのメッセージを再生成

設定ファイル（~/.git-sc）:

• providers = [“gemini”, “codex”, “claude”]（配列順が優先度）
• language = “Japanese”
• [models] で各プロバイダーのモデルを指定（claude = “haiku” など）

Claude Code連携: Stopフックに git-sc –all –yes を設定するとセッション終了時に自動コミット可能

$20分使い切ったのにまだ使える…？Cursor Free Usageをサポート回答で解明

• URL: https://zenn.dev/owayo/articles/1f3a5e73aeb03c
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Cursorの月間使用量を使い切った後にダッシュボードの「Free Usage」が増え続ける現象について、著者がサポートに直接問い合わせて仕組みを解明した記事。Free Usageとは月額プランの使用量を使い切った後に自動的に付与される無料の追加枠であり、完全無料でOn-Demand課金の前に消費される緩衝材として機能する。付与量は固定ではなくサーバーの需要とキャパシティに応じてリアルタイムで動的に決定されるため保証はなく、上限は管理画面の観察で概ね100ドル程度とされる。Free Usageが尽きるとOn-Demand Usageを有効化する必要があり、有効化しない場合は翌月リセットまで待つことになる。

詳細

Cursorの「Free Usage」機能についてサポートへの直接問い合わせで得た情報をまとめた記事。

使用量の消費順序（サポート回答より）:

1. Included Usage（月額プランに含まれる使用量）を最初に消費
2. Free Usage（無料の追加使用枠）をIncluded Usage使い切り後に消費
3. On-Demand Usage（従量課金）をFree Usageも使い切った後に消費

Free Usageの特徴:

• 完全無料（追加料金なし）
• 標準モデル・プレミアムモデル両方に適用
• 自動的に付与される（申請不要）
• 固定量ではなく変動する（システムの利用可能性と使用パターンによる）
• リアルタイムで動的決定（demand and system capacityに基づく）
• 著者の観察では上限は約100ドル程度

目的（サポートの説明）: 「The goal is to ensure continuity, not to replace the included usage quota.」 突然使えなくなる事態を避け、スムーズに作業を継続させるための緩衝材として設計されている

注意点:

• 付与量の保証はない
• メインの使用量として計算に含めるべきでない
• 上限到達時はOn-Demand Usageを有効化するか翌月のリセットを待つ

AIコーディングアシスタント、AIエディタをパパッと開ける、macOS向けの高速ランチャー「Ignitero Launcher」を自作した話

• URL: https://zenn.dev/owayo/articles/219f6950b80111
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: AIコーディングアシスタントをプロジェクトに応じて開き分けたいというニーズに対応するため、Tauri v2製のmacOSステータスバー常駐ランチャー「Ignitero Launcher」が自作・公開された。ディレクトリごとに開くエディタ（Cursor、Windsurf、VS Code）を設定でき、矢印キー一発でターミナルも開けるため、Claude Code・Codex CLI・Gemini CLIのような端末ベースのツールに素早くアクセスできる。SQLiteキャッシュとファジーマッチング、Carbon APIによるIME制御を組み合わせた高速な日本語インクリメンタル検索を実装し、Option+Spaceのグローバルホットキーで常にランチャーを呼び出せる。Codexを使ったコードレビューで検索スクロールやキャッシュ処理など複数のパフォーマンス改善も実施されている。

詳細

Ignitero Launcher: Tauri v2製のmacOSステータスバー常駐型ランチャー。Dock非表示、ソースコードはGitHubで公開。

技術スタック:

• フロントエンド: React 18 + TypeScript + Vite + Ant Design
• バックエンド: Rust + Tauri v2 + SQLite（rusqlite）+ fuzzy-matcher

主な機能:

• 柔軟なディレクトリ管理: 「このディレクトリ自身」と「配下のディレクトリ」を個別に設定。開き方（表示しない/Finderで開く/エディタで開く）とエディタ（Windsurf/Cursor/VS Code）を選択
• .code-workspaceファイルが存在する場合はそれを優先して開く
• ターミナル統合: →キーでターミナル（macOSデフォルト/iTerm2/Warp）を直接開く。open -a Terminal/iTerm/Warp コマンドのシンプルな実装
• インストール済みアプリ・ターミナルのみを選択肢に表示（/Applications配下の存在確認）
• 高速検索: Carbon APIで英字入力モードを強制、wanakanaでかな→ローマ字変換補完
• 履歴による順位最適化: 検索キーワード×パスの組み合わせを最大50件記録して上位表示
• 自動キャッシュ更新: 起動時・1〜24時間の自動更新・手動更新の3モード

パフォーマンス改善（Codexのコードレビューで実施）:

• エディタアイコンのIPCキャッシュ化
• 設定保存時の不要なキャッシュ再構築を削除
• useRefを使ったスクロール最適化（behavior: ‘auto’ で連続入力時の遅延解消）

Git rebaseでコミット整理とブランチ管理を改善

• URL: https://zenn.dev/owayo/articles/3e72b600e504d5
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: git rebaseを使ったコミット履歴の整理と、ブランチの分岐元変更による開発フロー改善を体系的に解説した記事。fixup・squash・drop・editコマンドの使い分け、過去のコミットメッセージの変更方法、mergeの代わりにrebaseを使うメリットを扱っている。rebase後のforce pushについては–force-with-lease –force-if-includes（Git 2.30以降）による安全な方法が紹介されており、チーム開発での実践的な運用を想定した内容になっている。JetBrains IDEからのGUI操作についても併記されている。

詳細

• コミット整理コマンド: fixup（前のコミットに統合しメッセージ破棄）、squash（統合しメッセージ編集）、drop（コミット削除）、edit（コミット分割・内容修正）
• editコマンドの手順: git reset HEAD^ でコミットを取り消し → 個別にadd・commitで分割 → git rebase –continue
• 過去コミットのメッセージ変更: git rebase -i で対象をeditに変更 → git commit –amend -m “…” → git rebase –continue
• mergeをrebaseに変える利点: 直線的な履歴・MRに自分の変更のみ表示・コンフリクト解決が1回で済む
• rebase後のforce pushに git push –force-with-lease –force-if-includes を推奨（Git 2.30以降）
  • –force-with-lease: ローカルが把握するリモート状態と実際のリモートを比較し、誰かが先にpushしていた場合は拒否
  • –force-if-includes: fetchした後に他者がpushした変更の誤上書きを防ぐ追加保護
• ~/.gitconfigのエイリアス設定: pushf = push –force-with-lease –force-if-includes
• JetBrains IDE: gitパネルからコミットを右クリックして「ここから対話的にリベース」でGUI操作可能

Claude Code に cc というエイリアスをつけたら PC がハングした話（原因は別でした）

• URL: https://zenn.dev/owayo/articles/6190821ac1dd1e
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: alias cc=‘claude’を設定した直後にtree-sitterのメモリ暴走（43GB消費）が発生し、エイリアスが原因だと誤認した顛末を記録した記事。実際にはtree-sitterがRustのstd::process::Command（execvp）でコンパイラを直接起動するためシェルエイリアスは無効であり、真の原因はtree-sitter v0.26.6の既知のメモリ問題（15MB・5989状態のパーサーでRSS 8GB以上に達する）だったことが後から判明した。ccというUnix標準のコマンド名をエイリアスに使うこと自体の危険性（Makefileやシェルスクリプト経由での意図せぬClaude Code起動）についても整理されている。

詳細

alias cc=‘claude –dangerously-skip-permissions –model opus’設定後にtree-sitter test実行でメモリ暴走した事例の原因調査と教訓。

• 誤認プロセス：which ccでエイリアスが確認できた→「ccがClaude Codeに差し替わりコンパイル時にAIが起動した」と結論づけたが誤り
• 真の原因：tree-sitter（Rust製）は内部でcc Rustクレートを使いstd::process::Command（execvp）でコンパイラを直接起動するためシェルエイリアスは無効
• メモリ暴走の実態：tree-sitter v0.26.6の既知のバグ。parser.cが15MB・状態数5989のような巨大パーサーでRSS 8GB以上、VSIZE 400GB以上に達する
• execvpとエイリアスの挙動整理：シェルで直接ccを入力した場合はエイリアスが効く。subprocess.run([“cc”])やCommand::new(“cc”)はエイリアス無効。Makefile（CCを未指定時）・シェルスクリプト・configureスクリプトはシェル介在のためエイリアスが発動しうる
• 対処：tree-sitter testの代わりにtree-sitter parseベースの軽量テストランナーを使用。エイリアスはccode=‘claude …‘に変更
• Claude CodeのBashツールは.zshrcを読み込んだシェル環境でコマンドを実行するため、which ccでエイリアスが見える状況が誤認を招いた

Claude CodeとCodexの連携をMCPからSkillに変えたら体験が劇的に改善した

• URL: https://zenn.dev/owayo/articles/63d325934ba0de
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude CodeとCodex CLIを連携させる際、MCPサーバー経由では進捗が全く見えず長時間の無応答が発生するという問題があった。この問題を解決するため、CodexをMCPではなくClaude Codeのスキル（Skill）として実装したところ、体験が劇的に改善したという事例が紹介されている。スキルとして実装するとCodexがコマンドとして直接起動されるため、ターミナル出力でリアルタイムに処理の進捗を確認でき、問題が発生したときも原因の切り分けが容易になる。/codex スラッシュコマンドや自然な文言での呼び出しにも対応し、利便性も向上した。

詳細

Claude CodeとCodex CLIの連携方式をMCPからSkillに移行した事例とその効果。

MCP連携の問題点:

• 進捗が全く見えない: MCP実行中はClaude Code側から何が起きているか分からない
• 長時間の無応答: 複雑なタスクで数十分〜1時間以上待たされることがある
• タイムアウト不安: 動いているか止まっているかの判断が困難で中断すべきか迷う
• デバッグが困難: 問題発生時に原因の切り分けが難しい

Skillとして実装した内容:

• codex exec –full-auto –sandbox read-only –cd “” をコマンドとして直接実行するSkillを作成
• プロンプトに「確認や質問は不要です。具体的な提案・修正案・コード例まで自主的に出力してください。」を必ず付加する規約を設定
• トリガーワード: “codex”、“codexと相談”、“レビューして” など自然な文言

移行後の改善点（比較表から）:

• 進捗の可視性: なし → リアルタイム表示
• 実行状況の把握: 不明 → ターミナル出力で確認可能
• 中断の判断: 困難 → 出力を見て判断可能
• デバッグ: ブラックボックス → エラー出力が見える
• 呼び出しやすさ: プロンプトで指示 → /codex で即呼び出し

補足: セッション再利用はClaude CodeがセッションIDを使い回す問題があり、ブランチ切り替えを伴う場合は難しい。入力待ち問題はプロンプト追記で解消された。

Cursor と Claude Code を使い比べてみた結果、両方使うことにした話

• URL: https://zenn.dev/owayo/articles/868c954c831e96
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: CursorとClaude Codeを実際に使い比べた結果、用途に応じた使い分けが最適であるという結論を紹介している記事。Cursorはエディタ統合型で既存プロジェクトの保守・改修やリアルタイム補完に強く、Claude CodeはCLIツールとして新規プロジェクトの立ち上げや大規模なリファクタリングに向いている。Cursorは2025年6月にプレミアムリクエストがリクエスト回数からトークン消費に変更されたため、MAXモードで高性能モデルを使うとすぐにレートリミットに達する問題が生じている。Claude Codeはレートリミットに達すると最長5時間待機が必要になるが、CLAUDE.mdへの規約記載による一貫したコード生成は有効である。

詳細

CursorとClaude Codeの比較記事（2025年6月時点の情報）。

主な仕様比較:

• 提供形態: Cursor（VSCodeベースIDE）vs Claude Code（CLIツール）
• 料金: 両者ともPro $20/月〜Ultra/Max $200/月
• AIモデル: Cursor（GPT-4.1/Gemini 2.5 Pro/Claude 4.0など複数選択可）vs Claude Code（Claude 4.0）
• コード補完: Cursor（リアルタイム）vs Claude Code（なし）
• レートリミット: Cursor（月500クレジットの高速リクエスト）vs Claude Code（5時間あたりの使用量）

Cursor向きのケース:

• 既存プロジェクトの保守・改修（プロジェクト全体理解・Git統合強力）
• リアルタイムコード補完が必要な場面
• AIが生成したコードを1つずつ適用・拒否して確認したい場合
• Ruleによるコード生成の使い分けをしたい場合

Claude Code向きのケース:

• 新規プロジェクトの立ち上げ（ボイラープレート生成から実装まで一気に）
• 大規模なリファクタリング（複数ファイルにまたがる変更）
• 短期集中型の開発

現状の問題点:

• Cursor: 2025年6月の仕様変更でMAXモード使用時にリクエスト回数からトークン消費に変更、上限到達が早くなった
• Claude Code: レートリミット到達で最長5時間待機が発生、カスタムスラッシュコマンド変更時に再起動が必要

著者の結論: メインはCursor、新規プロジェクト立ち上げや大規模リファクタリング時はClaude Codeというハイブリッド運用

Claude CodeのHooksで自動コミット! AIがコミットメッセージも考えてくれるツールを作った

• URL: https://zenn.dev/owayo/articles/9461d3ebb3b77a
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude CodeのStop Hooksを利用して、AIによる変更を自動的にGitコミットするPython製ツール「claude-code-auto-commit」が公開された。Claude Codeが作業を終えるたびにフックが起動し、変更の有無を確認してからGemini CLIでConventional Commits形式のコミットメッセージを生成し自動コミットする。タイムアウト処理（20秒）や差分の5000文字制限によってGemini CLIのエラーを防ぐ工夫がされており、CLAUDE_CODE_AUTO_PUSH=1 の環境変数を明示的に設定した場合のみ自動プッシュが有効化される安全設計になっている。コミット言語やデフォルトメッセージも環境変数でカスタマイズ可能。

詳細

claude-code-auto-commit: Claude Code の Stop Hook で自動コミットするPython製ツール。

仕組み:

• Claude CodeのStop Hookとして python3 /path/to/auto-git-commit.py を登録（timeout: 30秒）
• Gitリポジトリ確認 → 変更確認 → Gemini CLIでメッセージ生成 → git commit の順で実行

環境変数による設定:

• CLAUDE_CODE_COMMIT_LANGUAGE: コミットメッセージの言語（デフォルト: 日本語）
• CLAUDE_CODE_DEFAULT_COMMIT_MESSAGE: Gemini失敗時のフォールバックメッセージ（デフォルト: “chore: Claude Codeによる自動修正”）
• CLAUDE_CODE_AUTO_PUSH: 自動プッシュの有効/無効（デフォルト: 0=無効、1で有効化）

実装上の工夫:

• Gemini CLIに20秒のタイムアウトを設定（subprocess.run timeout=20）
• 差分を5000文字に制限してGemini CLIの入力過多エラーを防止
• AUTO_PUSHはデフォルト無効で環境変数で明示的に有効化するまで動作しない

生成されるコミット形式: Conventional Commits（feat/fix/refactorなどのプレフィックスを自動選択）

インストール: git clone https://github.com/owayo/claude-code-auto-commit.git してパスを設定に記載

cmux：AI エージェント時代のマルチタスクターミナル入門

• URL: https://zenn.dev/owayo/articles/9671573d948e62
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 複数のAIエージェントを並行運用する際の状態管理問題に特化したmacOSネイティブターミナルcmuxの紹介記事。Ghosttyと同じlibghosttyをレンダリングエンジンに使いつつ、エージェントの入力待ち状態を通知リング・サイドバーバッジ・デスクトップ通知の3経路で知らせる仕組みが特徴。縦タブのサイドバーにGitブランチ・作業ディレクトリ・ポート番号をリアルタイム表示し、アプリ内ブラウザでドキュメントを並列参照できるなど、AIエージェント協調作業向けの独自機能が紹介されている。

詳細

manaflow-ai開発のmacOSネイティブターミナルcmuxの機能紹介と設定例。brew tap manaflow-ai/cmux && brew install –cask cmuxでインストール可能。

• エンジン：Ghosttyと同じlibghosttyで描画。Ghosttyの設定ファイルからテーマ・フォント・色設定をそのまま読み込める
• 通知システム：入力待ちペインに青い通知リング表示、サイドバーバッジ、macOS通知センター（OSC 777対応）、カスタムサウンド。⌘+Shift+Uで未読通知ジャンプ
• 縦タブ（サイドバー）：Gitブランチ名・作業ディレクトリ・リスニングポート（クリックでブラウザ表示）・最新通知テキストを表示
• 分割ペイン：⌘+D（水平）、⌘+Shift+D（垂直）、⌥+⌘+矢印でペイン間移動。tmux互換コマンドも使用可
• アプリ内ブラウザ：⌘+Shift+Lで開閉。Chrome/Firefox/SafariからCookieインポートでログイン済みサービスにアクセス可
• Claude Code・Codex CLIの入力待ち・処理完了をHooks設定なしで自動検出する統合機能あり
• セッション永続化：再起動後も分割レイアウト・作業ディレクトリ・ブラウザ履歴が復元される

GitLab MRレビュー自動化の3年間の試行錯誤 - APIの限界をAIエージェントで突破した話

• URL: https://zenn.dev/owayo/articles/b7ab1ed5bb88fe
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitLab MRのAIコードレビュー自動化を2023年から試み、OpenAI API直接呼び出しとPR Agentの2度の失敗を経て、2025年にCodex CLI + MCP（Serena + Context7）の組み合わせで実用レベルに達したという3年間の試行錯誤が詳述されている。失敗の本質は「GitLab APIのdiff情報だけではコードベース全体のコンテキストが不足する」という点にあり、AIエージェントがローカル環境でリポジトリを直接探索できるようにすることで問題が解消された。Codex CLIの –full-auto モードでCI/CD環境での完全自動実行を実現し、SerenaによるセマンティックコードのインデックスとContext7の公式ドキュメント参照を組み合わせて、人間のレビュアーが見落としがちなエッジケースまで指摘できる精度を達成している。

詳細

GitLab MRレビュー自動化の3年間の変遷と現在のアーキテクチャ（GitLab Self-Managed、Kubernetes環境）。

失敗の歴史:

• 2023年（OpenAI API直接呼び出し）: List merge request diffs APIでdiff取得 + 周辺コード手動選定 → 依存関係・呼び出し元追跡不可、コンテキスト漏れが頻発
• 2024年（PR Agent）: APIベースのlimitは同じ。大規模コードベースで精度低下、プロジェクト固有ルール適用困難

現在のアーキテクチャ（2025年）:

• Webhook API（FastAPI on Kubernetes）: @review-bot メンションを検知してGitLab CI/CDパイプラインをトリガー
• レビュージョブ（Docker + GitLab CI）: 専用Dockerイメージに Codex CLI + Serena MCP + Context7 MCP を搭載、主要プロジェクトのSerenaインデックスを事前生成
• git diff ${BASE_SHA}..${HEAD_SHA} でGitLab APIではなくgit操作で正確なdiffを取得
• Serena MCP: シンボル情報をインデックス化しAIがコードベースを自律探索可能に
• Context7 MCP: 外部ライブラリの公式ドキュメントをリアルタイム参照

プロジェクト固有カスタマイズ:

• AGENTS.md に全プロジェクト共通ルールを記載し、DBマイグレーションファイルが含まれる場合などは条件付きで専用観点を追加
• レビューテンプレートで致命的/重要/軽微/提案の4段階と、マージOK/条件付きOK/要修正/パイプライン失敗の総評を規定

レビュー品質: バグ検出・依存関係の影響範囲指摘で実用レベルに達したと評価

Claude Code, Curosr, Windsurf のHooks設定を10倍楽にする claw-hooks

• URL: https://zenn.dev/owayo/articles/b9dcbf7322b329
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude Code・Cursor・WindsurfなどのAIコーディングエージェントのHooks設定を、PythonやBashスクリプトを書かずにTOML設定だけで定義できるRust製ツール「claw-hooks」が公開された。エージェントごとに異なるJSON形式を内部で吸収するため、1つの設定ファイルで複数エージェントに対応できる。危険コマンドのブロックは rm_block = true の1行で完結し、AST解析（tree-sitter-bash）によってsudoやパイプ経由の間接的なコマンドも正確に検出する。ファイル保存時の拡張子別フォーマッター実行も extension_hooks に1行ずつ書くだけで設定でき、従来の複雑なスクリプトを大幅に簡素化できる。

詳細

claw-hooks は複数AIコーディングエージェントのHooks設定を統一するRust製シングルバイナリ（起動時間 <10ms）。

解決する問題:

• エージェントごとにHooksのJSON構造が異なり（Claude Code: tool_input.command、Cursor: command直下、Windsurf: tool_info.command_line）、同じ機能でも別々のスクリプトが必要だった問題を解消

主な機能:

• rm_block = true、kill_block = true、dd_block = true の1行でデフォルトメッセージ付き危険コマンドブロック
• [[custom_filters]] でカスタムフィルターを定義。コマンドのみ（全ブロック）と command + args の組み合わせ（サブコマンド単位制御）の2モード
• [extension_hooks] マップで拡張子別フォーマッター自動実行（例: “.rs” = [“rustfmt {file}"]）
• [[stop_hooks]] でエージェント終了時通知
• –format cursor / –format windsurf フラグで各エージェントのJSON形式に自動変換
• tree-sitter-bash によるAST解析で sudo rm、echo “setup” | xargs rm なども検出可能

設定の伝達方法:

• Claude Code: ~/.claude/settings.json に claw-hooks hook を登録
• Cursor: ~/.cursor/hooks.json に claw-hooks hook –format cursor を登録
• Windsurf: ~/.codeium/windsurf/hooks.json に claw-hooks hook –format windsurf を登録

インストール: brew install owayo/claw-hooks/claw-hooks

Gemini CLIでMinecraft(Java版)の自律Botを動かす

• URL: https://zenn.dev/owayo/articles/bcbbc82eb49511
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Gemini CLIと Minecraft Java版用MCPサーバーを組み合わせてゲーム内を自律的に操作するBotを実装し、その可能性と限界を検証した実験記事。Gemini CLIは1日1000リクエストまで無料で利用でき、~/.gemini/settings.json にMCPサーバー設定を追加するだけでMinecraftへの基本的な移動・ブロック操作・チャットが可能になる。実際に動かした結果、コマンドに対するレスポンスのラグや周囲環境の認識不足（モンスター位置・崖の検出不可）が課題として浮かんだ。現時点ではリアルタイム操作や複雑な建築には実用的でないが、視覚情報の取得機能拡張やレスポンス速度向上で将来的な改善が期待される。

詳細

Gemini CLI + MCP + Minecraft Java版（1.21.4）の自律Bot実装実験。

セットアップ手順:

• Minecraft Java版でシングルプレイヤーワールドを作成しLAN公開（ポート番号をメモ）
• Gemini CLI の ~/.gemini/settings.json に mcpServers.minecraft の設定を追加
  • command: “npx”、args: ["-y", “github:yuniko-software/minecraft-mcp-server”, “–host”, “”, “–port”, “”, “–username”, “gemini”]
• MCPサーバーはyuniko-software/minecraft-mcp-serverが最も活発に開発中

MCPサーバーが対応するMineraft操作:

• 移動、ブロック設置・破壊、チャット（クラフトは未対応）

実際の動作確認例:

• 「プレイヤーについて来て」→ 基本移動は正常動作
• 「周囲にある白樺の木を10本切って」→ ブロック破壊は可能

確認できた課題:

• レスポンスのラグ: コマンド送信から動作まで顕著な遅延があり、リアルタイム操作に不向き
• 周囲認識不足: モンスター位置・動き・崖・穴を認識できず、戦闘や安全な移動が困難
• 複雑な作業の精度: 建築など連続した動作の精度が低い

注意点: Minecraftには独自の「MCP（Mod Coder Pack）」という用語があるため、Gemini CLIに指示する際は「mcp server」と明示しないと誤動作する

今後の可能性: 画面情報（視覚情報）をGeminiに送信できるようになれば周囲認識が大幅改善できる見通し

これから始める Cursor エディター!

• URL: https://zenn.dev/owayo/articles/cbca6b558918bd
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 社内でCursor Businessを導入した著者が、エディタの概要・プラン比較・推奨設定・主要機能をまとめた入門ガイド。VSCode互換のAIエディタとして、Tab補完・Ask・Agent・Edit・Command+Kの各機能の使い分けと、MCP対応・@シンボルによるコンテキスト指定・コードベースインデックスの仕組みが解説されている。Bug Finder機能（現ベータ）のRun Smartが追加課金設定の$0上限でも課金される点など、実際の運用で注意すべき挙動についても触れている。

詳細

• プラン: Hobby（無料・2週間Proトライアル付き・補完2000回・プレミアム50回）、Pro（$20/月・補完無制限・高速プレミアム月500回）、Business（$40/ユーザー/月・強制プライバシーモード・SSO等）
• 推奨設定: プライバシーモードOn、コードベース自動インデックスOn、User Rulesで定型プロンプト設定
• モデル: claude-3.7-sonnetを基本推奨。claude-3.5-haikuは1リクエスト=1/3回カウント
• Pro/BusinessでUsage-Based PricingのEnable for usage-based for premium modelsをOffにするとclaude-3.7-sonnetが低速で使い放題になる（失敗リトライが必要になる場合あり）
• Bug Finderのrun Smartは、追加課金上限$0設定でも課金される（どんな小ファイルでも約$2.7）
• @シンボル: @Files（特定ファイル参照）、@Code（選択範囲）、@Doc（ライブラリドキュメント）、@Web（Web検索）、@Link（URL参照）
• MCP: AgentモードでのみMCPツールが利用可能
• Cursor Stats拡張でプレミアムリクエスト残数をステータスバーに表示できる

pnpm, uv, cargo… 言語ごとの依存更新コマンドを統一するCLI「depup」を作った

• URL: https://zenn.dev/owayo/articles/ce0da822a296ca
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Node.js・Python・Rust・Go・Ruby・PHP・Javaの7言語に対応した依存関係アップデートCLI「depup」がRustで実装・公開された。言語ごとに異なるコマンド（pnpm update、uv lock –upgrade、cargo updateなど）を1コマンドに統一し、マニフェストファイル（Cargo.toml、package.jsonなど）を直接更新する。バージョン範囲形式（^、~など）を維持したまま最新版に更新でき、固定バージョンはデフォルトでスキップする。Ageフィルター（–age 2w）でリリースから一定期間を経過したバージョンのみを対象にすることで不安定な最新版を回避でき、pnpmワークスペースやTauriのようなマルチ言語構成にも対応している。

詳細

depup は7言語の依存関係更新を統一するRust製CLIツール。Homebrewでインストール可能（brew install owayo/depup/depup）。

対応言語と設定ファイル:

• Node.js: package.json（npm）
• Python: pyproject.toml（PyPI）
• Rust: Cargo.toml（crates.io）
• Go: go.mod（Go Proxy）
• Ruby: Gemfile（RubyGems）
• PHP: composer.json（Packagist）
• Java: build.gradle(.kts)（Maven Central）

主な特徴:

• ロックファイルではなくマニフェストファイルを直接更新する
• バージョン範囲形式を維持: “^1.2.3” → “^2.0.0”、"~1.2.3" → “~1.3.0”
• ピン固定バージョン（“1.2.3"や”==1.2.3"）はデフォルトでスキップ
• –age 2w でリリースから2週間以上経過したバージョンのみ対象
• –only lodash、–exclude react などのフィルタリングオプション
• JSON出力（–json）とdiff出力（–diff）でCI/CD連携も容易
• –install フラグで更新後にインストールコマンドを自動実行

実装上の工夫:

• PEP 440準拠のPythonバージョン形式対応
• Gradle変数定義パターン（def kotlinVersion = ‘…’）への正規表現対応
• OpenSSLを避けてrustls-tlsに切り替えてクロスコンパイル問題を解決

GitLabと連携するMCP Serverを作った

• URL: https://zenn.dev/owayo/articles/e4c4496e6d79e7
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitLabとAIアシスタント（Claude/Cursor等）を連携させるMCP Serverを自作して公開したという記事。パイプライン失敗時のコンソール出力取得、MRの未解決コメント取得、MRの変更差分取得（未コミット変更を含むローカル最新状態）という3機能を提供する。社内でCursor Businessを導入するにあたり、開発効率化を目的として開発された。uvを使ったPython実装で、Claude for DesktopとCursorの両方への接続設定が記載されている。

詳細

• リポジトリ: github.com/owayo/gitlab-mcp-server
• 提供する3機能:
  1. get_pipeline_failed_jobs(): 失敗ジョブのコンソール出力（ジョブ名・ステータス・詳細ログ）を取得してAIが修正
  2. get_review_comments(): MRの未解決コメント（解決済み・ファイル非紐付けは除外）を取得してAIが修正
  3. get_review_changes(): MRのベースコミットから現在のローカル最新状態までの差分を取得（未コミット変更を含む点が特徴）
• 実装: Python + uv。GitLab APIアクセストークン（read_api権限）が必要
• Claude for Desktop設定: claude_desktop_config.jsonにmcpServersセクションを追加
• Cursor設定: プロジェクトの.cursor/mcp.jsonに定義
• 現状の課題: 「レビューして」と依頼するとパイプライン情報取得・指摘取得・レビューの全機能が動いてしまい、機能単体での呼び出しができない（改善検討中）

料金体系が変わった Cursor から Windsurf へ乗り換え

• URL: https://zenn.dev/owayo/articles/f10d4f290f0607
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Cursorが2025年6月に料金体系を月500回の高速プレミアムリクエストから月額20ドル上限制に変更したことを受け、WindsurfへのAIエディタ乗り換えを解説した記事。WindsurfはProが月15ドル・Teamsが月30ドルとCursorより安く、SWE-1モデルが0クレジットで利用可能なプロンプトクレジット500回制を維持している。機能面ではCursorに明示的なPlanモードと内蔵ブラウザがあるのに対し、WindsurfにはDeepWikiというシンボルへのAI生成ドキュメント表示機能がある。MCP導入はWindsurfのMCP Marketplaceがインストールボタン一発で設定でき、エディタ内で完結する点が優れている。CursorのRuleやSlashコマンドはWindsurfのRules・Workflowsとして移行できる。

詳細

CursorからWindsurfへの乗り換えガイド。Cursor料金改定（2025年6月、Teamsプランにも適用）を契機として。

料金比較:

• Windsurf Pro: $15/月 vs Cursor Pro: $20/月
• Windsurf Teams: $30/月 vs Cursor Teams: $40/月
• Windsurf: プロンプトクレジット500回/月 + SWE-1モデルが0クレジットで利用可能

機能比較（主な差異）:

• Planモード: Cursor（明示的あり）vs Windsurf（デフォルト有効で明示的操作なし、複雑タスクで自動的に計画立案）
• ブラウザ操作: Cursor（エディタ内蔵）vs Windsurf（Chrome DevTools MCPなどで代替）
• MCP導入: Cursor（ドキュメント参照してJSON手動設定）vs Windsurf（MCP Marketplaceからインストールボタン一発）
• 用語: Cursor（Agent）vs Windsurf（Cascade）

Windsurf固有の機能:

• DeepWiki: シンボルへのCmd+Shift+Click（macOS）でAIが生成した詳細ドキュメントを表示。機能概要・パラメータ説明・使用例・関連クラスを表示し、「Add to Cascade」でコンテキストとして送信可能

設定の移行:

• Ruleの移行: Cascadeパネルのメモ帳アイコン → Rules タブ（Cursorからのインポート機能あり）
• Slashコマンドの移行: Workflows タブ

Windsurf推奨設定:

• Disable Telemetryを有効化（学習無効化）
• Cascade Auto Execution: Auto または Turbo
• Enable Sounds for Cascade（処理完了通知音）

Claude Code実行予約ツール「Claude Code Runner」でストレスフリーな開発を

• URL: https://zenn.dev/owayo/articles/fda9deb6741958
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude CodeのRate Limitが深夜に解除されるという実用上の問題を解決するために、Tauri 2.0で開発されたmacOS向けデスクトップアプリ「Claude Code Runner」が公開された。指定時刻にClaude Codeコマンドを自動実行し、Rate Limitを検出したら自動リトライする機能を持つ。iTermをAppleScriptで制御する設計で、新規ウィンドウモードと既存セッションモードを選択できる。ソースコードはGitHubで公開されており、Tauri製のため軽量・高速に動作する。

詳細

• ツール名: Claude Code Runner（Tauri 2.0製、macOS専用）
• 主な機能: 指定時刻のスケジュール実行、Rate Limit自動検出とリトライ、リアルタイム監視、設定の永続化、iTerm統合
• Rate Limit検出の仕組み: 60秒ごとにターミナル出力を監視し、「reset at」メッセージが3回連続で出現した場合にリセット時刻を解析して待機
• iTerm制御にAppleScriptを使用。「新規ウィンドウモード」と「既存ウィンドウモード（会話継続用）」を選択可能
• インストール: GitHubからビルド済みバイナリを取得、またはpnpm run tauri:buildでソースからビルド
• 初回起動時にmacOSのアクセシビリティ権限（システム設定 > プライバシーとセキュリティ > アクセシビリティ）の付与が必要
• Rate Limit処理モード: 自動リトライモード（解除まで待機して再実行）と終了モード（検出時に停止）の2種類
• リポジトリ: github.com/owayo/tauri-claude-code-runner

VanJS で素のDOM操作をリファクタしてみた

• URL: https://zenn.dev/ryo_kawamata/articles/1ad6e51eed13ae
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Chrome拡張Sky Follower Bridgeのcontent scriptにおける素のDOM操作をVanJSでリファクタリングした事例。VanJSはgzip後0.9kbと超軽量でトランスパイル不要のReactive UIフレームワークであり、Chrome拡張のcontent scriptのようにReactやVueのフルフレームワークを持ち込みにくい文脈で有効な選択肢となる。リファクタリング前はinsertAdjacentHTMLとaddEventListenerのクラス付け変えによるイベント管理で可読性が低かったが、VanJSのvan.state/van.deriveによる状態管理とコンポーネント分割により、UIとイベントの関連が一目でわかる宣言的なコードになった。

詳細

VanJSの特徴

• gzip圧縮後0.9kb、依存なし、トランスパイル不要
• JSXを使わず関数ベースのAPIで宣言的なUI構築
• van.state()で状態管理、van.derive()で状態から派生値を算出
• van.add(element, component)でDOMにコンポーネントをマウント

リファクタリング前の問題（insertAdjacentHTML + addEventListener）

• HTMLテンプレートリテラルでDOMを構築し、後からaddEventListenerを登録
• ボタンの状態変化はclassList.add/remove/containsとtextContent書き換えで直接操作
• UIとイベントロジックの対応関係が追いにくく可読性が低い

リファクタリング後の構造

• BskyUserCell, ActionButton, Avatar の3コンポーネントに分割
• ActionButtonはvan.state()で label, isStateOfBeing, isProcessing, isJustApplied の4状態を管理
• van.derive()でCSSクラス名を状態から派生（beingClass, processingClass, justAppliedClass）
• マウント処理: van.add(dom.parentElement, BskyUserCell({…})) の1行

適用場面

• Chrome拡張のcontent scriptのような制約のある環境
• 静的サイトにピンポイントでReactiveなUIを追加したいケース

RecastでASTを探索してコードを動的に変換する

• URL: https://zenn.dev/ryo_kawamata/articles/2038aa5eb42a5b
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: JavaScriptのAST（抽象構文木）を操作するライブラリRecastの機能と使用例を解説した記事。Recastはparse・visit・printの3ステップでコードの探索・変換・再出力ができ、namedTypes（型チェック）・builders（Nodeの生成）・prettyPrint（整形出力）などの補助APIも提供する。デフォルトはEsprimaパーサーだが、TypeScriptやJSXパーサーへの切り替えも可能。大規模コードベースでのリファクタリング自動化ツール（let→const置換、console.log削除、型アノテーション追加など）を作成する際に実用的に機能する。

詳細

Recastの基本フロー

• parse(): コード文字列をASTに変換
• visit(): ASTを探索し、特定Nodeを見つけて改変する（visitIdentifier、visitVariableDeclaration等のメソッドを登録）
• print(): ASTをコード文字列に再変換（変更されていない部分は元の書式を保持）

補助API

• types.namedTypes: Node型のチェックに使用（例: n.CallExpression.check(node)）
• types.builders: 新しいNodeを生成（例: b.callExpression(b.identifier(“add”), […])）
• prettyPrint(): コードを整形して出力（print()は元の書式を維持するが、prettyPrint()は整形する）

パーサーの切り替え

• デフォルト: Esprima JavaScript parser
• TypeScript対応: import TSParser from "recast/parsers/typescript" を第2引数に指定

実装サンプル（テストコード付き）

• let→const置換: visitVariableDeclarationでnode.kindを変更
• console.log削除: visitExpressionStatementでpath.prune()呼び出し
• use strict追加: visitProgramでbody.unshift()を使用
• 型アノテーション追加: TypeScriptパーサーでvisitFunctionDeclaration、b.tsTypeAnnotation(b.tsStringKeyword())でアノテーション生成

Astro + Vercel Serverless FunctionsでのreCAPTCHA v3の導入例

• URL: https://zenn.dev/ryo_kawamata/articles/2cc787af09ebce
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: AstroとVercel Serverless Functionsを使ったWebサイトにreCAPTCHA v3を導入する実装例。reCAPTCHA v3はバックグラウンドでユーザーの動きを検証してスコアを返す方式のため、「私はロボットではありません」チェックは不要。Server側はAstroのServer Endpointsとして実装し、シークレットキーとフロントエンドから受け取ったトークンでスコアを取得する。Vercelへのデプロイ時はhybrid出力モードと@astrojs/vercelアダプターを使い、reCAPTCHA APIエンドポイントのみサーバーサイドレンダリングとする設定が必要。

詳細

reCAPTCHA v3の概要

• バックグラウンドでユーザーの行動を解析してスコア（0.0〜1.0）を返す
• チェックボックスや画像選択操作が不要

実装構成（Astro + Vercel Serverless Functions）

1. reCAPTCHAコンソールでサイト登録

• サイトキーとシークレットキーを取得
• ドメインを登録

2. Server側（Astro Server Endpoints）

• src/pages/api/recaptcha.ts を作成
• シークレットキー＋フロントエンドから受け取ったトークンをGoogleのAPIに送信してスコア取得
• ファイル先頭に export const prerender = false; を追加（hybridモードでSSRを有効化）

3. Client側

• サイトキーをクエリパラメーターに含めてreCAPTCHAライブラリを読み込み
• 送信ボタン押下時に grecaptcha.ready → grecaptcha.execute でトークン取得
• トークンをAPIに送信してスコアを取得
• AstroコンポーネントとReactコンポーネント両方の実装例を提供

4. Vercelデプロイの設定

• npx astro add @astrojs/vercel でアダプターを追加
• astro.config.mjs で output: "hybrid" と adapter: vercel() を設定
• hybrid モード: デフォルトはプリレンダリング、export const prerender = false のファイルのみSSR

LangChain を使って Hacker News の日本語要約 Bluesky ボットを作ってみた

• URL: https://zenn.dev/ryo_kawamata/articles/98b7cc1c67ad0c
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: LangChainとFirebase Cloud Functionsを使ってHacker Newsのトップ記事を日本語要約しBlueskyに定期投稿するボットを構築した事例。PuppeteerWebBaseLoaderでページ本文を取得し、LangChainのSummarization Chain（map_reduce方式）でGPT-3.5による要約を生成して投稿する。詰まりどころとして、PuppeteerWebBaseLoaderのデフォルトがinnerHTMLを取得するためinnerTextに変更する必要があること、loadAndSplitでドキュメントを分割しないとトークン超過エラーが発生することの2点が挙げられている。Bluesky APIの300文字制限に合わせて句点で要約文を分割してスレッド投稿する仕組みも実装している。

詳細

システム構成

• Firebase Cloud Functionsの定期実行をトリガー
• Hacker News APIからトップ記事を取得
• LangChain（GPT-3.5）で日本語要約を生成
• Bluesky APIで記事タイトル+リンクをポスト、スレッドに要約を追加投稿
• Firestore で投稿履歴を管理（重複投稿防止）

LangChain実装の詰まりどころ

1. PuppeteerWebBaseLoaderのテキスト取得設定

• デフォルトではdocument.body.innerHTMLを使用するため、HTMLタグも要約対象に含まれトークンを無駄消費
• evaluateオプションでdocument.body.innerTextを指定する必要がある

2. loadAndSplitの利用が必須

• ドキュメントをloadSplit()で分割しないとSummarization Chainの恩恵を受けられない
• 文章量の多いページではモデルの最大トークン数を超過してエラーが発生する
• LangChainのSummarization Chainは分割されたドキュメントを再帰的に要約（map_reduce）

Bluesky投稿の実装

• 1投稿の文字数上限が300文字
• 要約文が300文字を超える場合は「。」「、」の句点を起点に分割してスレッド投稿

エゴサーチを自動化！GitHub ActionsとChatGPTでBlueskyの投稿を監視する

• URL: https://zenn.dev/ryo_kawamata/articles/ego-searcher
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 個人開発ツールSky Follower Bridgeの評判を監視するため、GitHub ActionsとChatGPT（gpt-4o-mini）を組み合わせたBluesky投稿の自動エゴサーチシステムを構築した事例。1時間ごとにBluesky APIで関連投稿を検索し、投稿内容の分類（対象か否か、バグ報告、スパムURL含有）をLLMで判定する。判定結果に応じて自動いいね・返信・Slack通知を実行し、多言語投稿の日本語翻訳も合わせて通知される。APIコストは1日約100投稿の分析で$0.01以下と低廉に収まっている。

詳細

対象ツールと背景

• Sky Follower Bridge（XからBlueskyへの移行ツール）の評判・不具合報告を見逃さないための監視システム

技術スタック

• GitHub Actionsで1時間ごとに定期実行
• Bluesky APIのsearchPostsで関連キーワードを検索（表記揺れ考慮）
• gpt-4o-miniで投稿内容を分析（json_object形式でレスポンス）
• 分析項目: 対象投稿か否か、バグ報告含有、スパムURL含有

アクションの振り分け

• 対象投稿 → 自動いいね＋投稿URLと日本語訳をSlack通知
• バグ報告 → @channelメンションでSlack通知
• スパムURL → 正規公式サイトへ誘導する返信＋Slack通知

コスト実績

• 1日約100投稿の分析でChatGPT APIコストは$0.01以下/日

設計上の利点

• Bluesky APIは無料で使えるためX APIと比べてコストが大幅に低い（X APIは月数千ドル規模）

Hono + Cloudflareでもくもく会用のDiscord Botを作ってみた

• URL: https://zenn.dev/ryo_kawamata/articles/hono-cloudflare-discord-app
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 茨城県水戸市のもくもく会コミュニティ運営補助のため、HonoとCloudflare Workers・D1を使ってDiscord BotをDiscord.jsなしで実装した事例。チェックイン機能（参加者の自己紹介と今日やることの投稿）、もくもく会の開始・終了通知（Cron Triggerで15:00と17:50に自動送信）、次回イベント概要生成の3機能を持つ。HonoのBindingsによるCloudflareスタックとの統合のしやすさ、Drizzle ORMとの組み合わせによる強力な型補完、TestHelperによるテストの書きやすさが評価されている。

詳細

主要機能

• /checkin コマンド: モーダルで自己紹介と今日やることを入力→フォーマットされた内容をチャンネルに投稿。2回目以降はD1から自己紹介を自動補完
• /mokumoku-start コマンド: スケジュール・ルール投稿。実行当日の15:00（LT通知）と17:50（終了通知）をCron Triggerで送信
• /generate-event-description コマンド: 次回イベント概要を生成（前回参加者の「今日やること」を自動埋め込み）

技術スタック

• Hono + Cloudflare Workers（サーバーレスHTTPハンドリング）
• Cloudflare D1（SQLite互換DBでチェックイン履歴を永続化）
• Drizzle ORM（D1操作、型補完が強力）
• Discord.jsを使わない純粋なJSでのDiscord Bot実装

実装のポイント

• /interaction エンドポイントでApplicationCommandObjectのTypeを見て処理を分岐
• モーダル表示はスラッシュコマンドのレスポンスでコンポーネントを返し、custom_idでサブミット結果と紐づけ
• Cron Triggerは毎週土日15:00と17:50に実行し、当日のEventモデルが存在する場合のみ通知を送る設計

開発体験

• bunx create-hono でプロジェクト作成、bunx deploy でCloudflareへデプロイ
• Hono TestHelperでほぼ全処理にテストを記述

ランナー OS の matrix を自動生成するアクションを作りました [GitHub Actions]

• URL: https://zenn.dev/snowcait/articles/0c3ef159a371e6
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitHub Actions のワークフローでランナー OS のリストをハードコードしていると、GitHub が新しいランナーを追加・変更するたびに手動メンテナンスが必要になる。snow-actions/list-github-hosted-runners アクションを使うと、JSON Schema Store で提供されているワークフロー用 JSON Schema からランナーリストを動的に取得でき、matrix に自動で反映できる。これにより、ランナー OS が更新されても workflow を変更せず最新の OS でテストが実行されるようになる。カスタムアクションやツールを複数 OS でテストするユースケースに特に有効。

詳細

従来の静的 matrix の問題点:

• ubuntu-22.04, ubuntu-20.04, windows-2022 などをべた書きしていると、GitHub 側でランナーが更新・追加されるたびに手動修正が必要

動的 matrix の実装例: jobs: runners: runs-on: ubuntu-latest outputs: list: ${{ steps.list.outputs.all }} steps: - id: list uses: snow-actions/list-github-hosted-runners@v1.0.0 test: needs: [ runners ] strategy: matrix: runner: ${{ fromJSON(needs.runners.outputs.list) }} runs-on: ${{ matrix.runner }}

仕組み: VS Code のワークフロー補完に使われている JSON Schema Store の JSON Schema にランナーリストが含まれており、そこを参照して動的生成している。

適しているユースケース: カスタムアクション、CLI ツール、クロスプラットフォーム対応ツールの各 OS でのテスト自動化。

@tabler/icons-svelte を @tabler/icons-svelte-runes へ移行する

• URL: https://zenn.dev/snowcait/articles/0e6cf8fd8df648
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Svelte 5 の Rune 対応に伴い @tabler/icons-svelte が @tabler/icons-svelte-runes へ改名・TypeScript対応された。移行には npm の再インストールと import パスの変更が必要で、ファイル数が多い場合に備えた移行シェルスクリプトが提供されている。スクリプトは git grep でアイコンをインポートしているファイルを特定し、perl で一括置換する構成になっている。

詳細

@tabler/icons-svelte から @tabler/icons-svelte-runes への移行手順

• 移行理由: Svelte 5 の Rune 導入に伴うパッケージ名変更、TypeScript 対応が追加された
• 変更点: import パスを ‘@tabler/icons-svelte’ から ‘@tabler/icons-svelte-runes’ へ変更するだけ（APIは同一）
• 移行スクリプト（migration.sh）の処理手順:
  1. npm remove @tabler/icons-svelte
  2. npm install @tabler/icons-svelte-runes
  3. git grep -lz で対象ファイルを列挙 → xargs + perl -pi -e で正規表現一括置換
• 注意点: 実行前に git commit でバックアップ必須。Windows では Git Bash を使用する
• パフォーマンスや機能面の変化はなし（TypeScript対応のみ）

Nostr プロトコルで SNS を作ってビットコインをもらった話

• URL: https://zenn.dev/snowcait/articles/3e52e8eae4b3b5
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Nostr プロトコルを使った分散型 SNS クライアント nostter を開発した経緯と、OpenSats というビットコインファンドから資金提供を受けた体験をまとめた記事。Nostr はクライアントサーバーモデルでサーバー（リレー）は中継のみを担い、ビジネスロジックはクライアント側に置く設計で、Svelte + Cloudflare Pages で実装されている。OSS 開発者が OpenSats に申請し承認されれば、ビットコイン建てで生活費を賄う規模の資金を得られることを自身の実例とともに紹介している。

詳細

Nostr プロトコルで SNS クライアントを開発し OpenSats から資金を受けた記録

• Nostr の設計: WebSocket ベースのリレーはデータの中継・保存のみ担当。ビジネスロジックはクライアント側に集約。クライアントとリレーは独立して開発・運用できる
• クライアント nostter の技術選定:
  • フレームワーク: Svelte（学習コストが低い）
  • ライブラリ: nostr-tools、rx-nostr（WebSocket と Rx の相性が良い）
  • ホスティング: Cloudflare Pages（SSR対応、ページごとのOGP設定のため）
• Nostr リレー開発の技術選定（開発着手中）:
  • Cloudflare Workers + Durable Objects（Lambda はコールドスタートと課金モデルの相性が悪い）
  • フレームワーク: Hono
  • DB 候補: Durable Objects 付属 SQL Storage か D1（容量上限 10GB が懸念）
  • 課題: リレー情報 JSON (https://) と WebSocket (wss://) を同一URIに置く NIP 仕様と cors ミドルウェアの相性問題
• OpenSats: ビットコイン・Nostr OSS 開発者への持続可能資金提供ファンド。契約期間は申請時に決定（著者は1年）。受取はビットコイン建て。日本人でも複数の受給者あり

文字数をカウントするサイトを作った

• URL: https://zenn.dev/snowcait/articles/40620fb90fbfb6
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 文字数カウントサイトの閉鎖を機に、より正確なカウントを目指した代替サービスを自作した記録。JavaScript の length プロパティはサロゲートペア・異体字セレクタ・ZWJ シーケンス等を正しく扱えないため、graphemesplit ライブラリや将来的には Intl.Segmenter を使ったグラフェム単位のカウントが必要になる。X（Twitter）の文字数換算には twitter-text ライブラリを使い、URL を半角23文字固定として換算する特殊ロジックにも対応している。

詳細

正確な文字数カウントの実装における技術的考察

• 元サイトのカウントロジック: text.replace(’\n’, ‘’).length（スペース込み）、/\s| /g で空白除去、改行数+1で行数計算など
• length の限界: サロゲートペア、異体字セレクタ、結合文字、ZWJ（絵文字シーケンス）を複数コードポイントとしてカウントしてしまう
• 対応方法:
  • graphemesplit ライブラリ: split(text).length でグラフェム単位カウント（現時点では推奨）
  • Intl.Segmenter: […new Intl.Segmenter(‘ja’, { granularity: ‘grapheme’ }).segment(text)].length（Firefox 125 以降で対応）
• X (Twitter) の文字数換算:
  • twitter-text（OSS）を使用。URLは半角23文字固定
  • Math.ceil(twitter.parseTweet(text).weightedLength / 2) で全角換算
• サイトの特徴: すべてクライアントサイドで処理し、通信なし

@tabler/icons-svelte のビルドを 10 倍速くする

• URL: https://zenn.dev/snowcait/articles/4fb5064177d996
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: @tabler/icons-svelte はパッケージのトップからアイコンをインポートすると開発サーバー起動時のビルドが非常に遅くなる問題がある。パッケージ直下ではなく各アイコンの実ファイルパスを直接インポートすることでビルド時に読み込むモジュール数が大幅に減り、ビルドが約 10 倍速くなる。変更前は 4351 モジュール処理で 1 分 6 秒かかっていたものが、変更後は 277 モジュールで大幅に短縮されている。この手法は開発時の体験改善として有効で、SvelteKit プロジェクトで多くのアイコンを使うケースで特に効果がある。

詳細

変更前のインポート（遅い）: import { IconHeart } from ‘@tabler/icons-svelte’;

変更後のインポート（高速）: import IconHeart from ‘@tabler/icons-svelte/dist/svelte/icons/IconHeart.svelte’;

ビルド結果の比較:

• 変更前: 4351 モジュール処理、約 1 分 35 秒（クライアント+サーバー合算）
• 変更後: 277 モジュール処理、大幅に短縮

理由: パッケージトップからのインポートはアイコンライブラリ全体のモジュールツリーを読み込んでしまうため。実ファイルパスを指定することで必要なアイコンのみを読み込む形になり、バンドルサイズと処理時間が削減される。

注意点: dist 以下のパス構造はバージョン変更で変わる可能性があるため、バージョンアップ時には確認が必要。

SvelteKit v2 へのバージョンアップ

• URL: https://zenn.dev/snowcait/articles/62bbf4c46301db
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: SvelteKit v2 へのアップグレード手順を実際の移行作業をもとにまとめた記事。前提として Svelte 4 が必要で、SvelteKit 自体は npx svelte-migrate sveltekit-2 コマンドによる自動マイグレーションが用意されている。npm install 時に –legacy-peer-deps が必要になる場合があり、その後もう一度 npm install することで peer deps が安定するという実運用上の注意点が共有されている。

詳細

SvelteKit v2 移行の手順と注意点

• 前提条件: Svelte 4 が必要。Svelte 3 以下からの場合は先に Svelte 4 へアップグレードする
• 自動マイグレーション: npx svelte-migrate sveltekit-2 を実行（対象ディレクトリは基本 src のみ）
  • package.json とソースコードを自動変更してくれる
  • モノリポの場合は各プロジェクトルートで実行
• 主な package.json の変更内容:
  • @sveltejs/adapter-auto: ^2 → ^3
  • @sveltejs/kit: ^1 → ^2
  • @sveltejs/vite-plugin-svelte: ^3 追加
  • vite: ^4 → ^5
  • vitest: ^0.34 → ^1
• npm install の注意: –legacy-peer-deps オプションが必要になるケースあり。その後もう一度 npm install を実行すると差分が出るため、2回実行が推奨
• 詳細な移行ガイド: 公式の “Migrating to SvelteKit v2” ページを参照

Svelte 3 から 4 へのバージョンアップ

• URL: https://zenn.dev/snowcait/articles/62cec4ce8de6a0
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Svelte 3 から 4 へアップグレードする際、依存パッケージを一括で上げようとすると依存関係エラーが発生するため、周辺ライブラリから段階的に移行する必要がある。eslint-plugin-svelte3 が deprecated となっており、eslint-plugin-svelte への移行と設定ファイルの書き換えが必要になる。svelte-i18n はバージョン 3.7.4 に既知のバグがあるため 4.0.0 以上か 3.7.3 に固定する対処が必要。Prettier は 3.0.0 以降で Svelte ファイルのフォーマットが正常に動作しないケースがあり、2 系に据え置くのが安全とされている。アプリ側コード自体の修正は不要で、移行は主にツールチェーン側の更新になる。

詳細

移行の基本方針は「WARN が出ない順に周辺ライブラリを先に更新してから Svelte 本体を上げる」という段階的アプローチ。

主な移行ステップ:

• eslint-plugin-svelte3 をアンインストールし eslint-plugin-svelte をインストール
• .eslintrc.cjs の extends・plugins・overrides を新しい形式に書き換え（svelte-eslint-parser を parser として指定）
• svelte-i18n をバグのある 3.7.4 を避けて 4.0.0 以上に更新
• @sveltejs/kit を最新に更新してから svelte 本体を更新
• Prettier は 3.0.0 以降で *.svelte フォーマットに問題があるため ^2.8.8 を維持

npx svelte-migrate@latest svelte-4 を実行すると View Transition API の local 属性のデフォルト変更など細かい移行もカバーできる。Prettier の回避策として –plugin オプション指定でフォーマットを動作させることも可能。

Vue 3 を GitHub Pages へデプロイ [GitHub Actions]

• URL: https://zenn.dev/snowcait/articles/80f646e0d70495
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Vue 3 プロジェクトを GitHub Pages にデプロイする方法として、アプリケーションとしてビルドする方式と CDN を使う方式の 2 通りがある。ビルド方式では GitHub Actions のカスタムワークフローを使い、Vite のビルドコマンドと成果物パスを指定してデプロイする。GitHub Pages のベース URL が / でない場合は Vite の Public Base Path 設定が必要で、build コマンドに –base=// を付けることで対応できる。CDN 方式では docs フォルダに HTML を直接置くだけでデプロイできるが、単一ファイルコンポーネントの構文は使えない。

詳細

ビルド方式でのデプロイ手順:

1. リポジトリ Settings > Pages で Source: GitHub Actions を選択
2. Static HTML テンプレートを Configure
3. ワークフローに npm ci && npm run build を追加
4. upload-pages-artifact の path を dist フォルダに変更

Vite のベース URL 設定（サブパスにデプロイする場合必須）:

• package.json の build コマンドを vite build –base=// に変更
• または vite.config.js で base を設定

CDN 方式:

• docs フォルダに index.html を作成して Vue を CDN から読み込む
• Settings > Pages で Source: Deploy from a branch + Branch: main /docs を設定
• 単一ファイルコンポーネント（SFC）は使用不可

使い分けの目安: アプリ規模が小さく TypeScript や SFC を使わない場合は CDN 方式が簡単。本格的なアプリはビルド方式を選ぶ。

GitHub Actions で Error: Can’t use ’tar -xzf’ extract archive file

• URL: https://zenn.dev/snowcait/articles/8ff19df6d387dd
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 2023 年 9 月 4 日以降、GitHub Actions で actions/checkout@v3 を使うと tar -xzf でのアーカイブ展開に失敗するエラーが報告されている。同日に actions/checkout@v4.0.0 がリリースされており、ダウンロード集中による一時的な負荷が原因と推測されている。対処法は再実行を待つか、v4 に更新することで、v4 への移行後にエラーが解消したという報告が多い。v4 では Node.js ランタイムが v20 になっているため、移行前に動作確認が推奨されている。

詳細

発生エラー: Error: Can’t use ’tar -xzf’ extract archive file: /home/runner/work/_actions/temp*.tar.gz. return code: 2.

発生条件: actions/checkout@v3 使用時、2023/09/04 以降

対処法1: しばらく待って再実行する（一時的な負荷の場合は自然解消） 対処法2: actions/checkout@v4 に更新する

• uses: actions/checkout@v4

注意点: v4 は Node.js v20 ランタイムに変更されているため、依存するスクリプトや他のアクションとの互換性を事前に確認する。

GitHub Actions から各プラットフォームへの通知方法まとめ

• URL: https://zenn.dev/snowcait/articles/a8fe50fac7125c
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitHub Actions から各種プラットフォームへ通知を送る方法を、公式アクション・公式アプリ・サードパーティアクション・Webhook の優先順位で整理した比較記事。GitHub CLI はランナーにプリインストール済みで追加設定不要。Slack は公式アクション（slackapi/slack-github-action）が提供されており、API・Incoming Webhook・ワークフロービルダーの 3 方式に対応。Microsoft Teams は公式アプリがあるがサードパーティアクションは Docker や古い Node.js 版が多く選択肢が限られる。Nostr・Bluesky・Discord・Chatwork はサードパーティアクションが利用可能で、コード例が示されている。

詳細

選定方針: 公式アクション・公式アプリを優先。Docker アクションと Node.js 12 のアクションは除外。テキスト自由入力できるものを選定。

プラットフォーム別の対応状況:

• GitHub: gh CLI がプリインストール済み。gh pr comment などで投稿できる
• Slack: slackapi/slack-github-action@v1.23.0（API・Incoming Webhook・ワークフロービルダー対応）
• Microsoft Teams: 公式アプリあり（GHEC対応、GHES 3.8でGA予定）。サードパーティアクションは選択肢が少ない
• Yammer: API 経由のみ。サードパーティアクションはゼロ
• Chatwork: okuzawats/chatwork-messaging-action@v1.0（apiToken と roomId が必要）
• Discord: stegzilla/discord-notify@v2（Webhook URL で設定）
• Twitter/X: snow-actions/tweet@v1.4.0（Consumer API Key と Access Token が必要）
• LINE: Docker アクションや古い JavaScript アクションが多く実用的な選択肢なし
• Nostr: snow-actions/nostr@v1.0.0（リレーと秘密鍵で設定）
• Bluesky: rg-wood/bluesky-post-action@v1（識別子とアプリパスワードで設定）

全アクションに if: ${{ always() }} を設定するとジョブ失敗時も通知できる。

URL が有効か判定する URL.canParse() メソッド

• URL: https://zenn.dev/snowcait/articles/cb3cb764658100
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: URL の有効性をチェックする際に従来は new URL() の例外を try-catch で処理する必要があったが、URL.canParse() という静的メソッドが主要ブラウザに追加された。古いブラウザ向けには同等の動作を提供する Polyfill を hooks などの初期ロードファイルに実装しておくことが推奨される。

詳細

URL.canParse() メソッドの解説と Polyfill 実装

• 従来の課題: new URL(invalidString) は例外を投げるため、URLの有効性チェックには try-catch が必要だった
• URL.canParse(): ブール値を返す静的メソッド。主要最新ブラウザでは使用可能
• Polyfill 実装例: if (!URL.canParse) { URL.canParse = (url, base) => { try { new URL(url, base); return true; } catch { return false; } }; }
• SvelteKit での実装場所: hooks ファイルが推奨（アプリ起動時の早い段階で読み込まれるため）
• 判定式の注意: if (‘canParse’ in URL === false) も動作するが、エディタによっては赤線が引かれる。!URL.canParse の方が実用的
• 代替手段: core-js など Polyfill 対応ライブラリの導入も選択肢

フロントエンドで OGP の情報を取得する

• URL: https://zenn.dev/snowcait/articles/d0f609d6366ef9
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: フロントエンドから外部サイトの OGP 情報を取得する際は CORS の制約により直接 fetch できないため、CORS Proxy サービス（corsproxy.io 等）を経由して HTML を取得し、ブラウザ標準の DOMParser で meta タグを解析する方法が有効。サーバーサイドで DOM をパースする方法と比べ、実装が手軽で Node.js の jsdom が不要という利点がある。Twitter Card の取得も同じ方法で対応できる。

詳細

フロントエンドから OGP 情報を取得する実装パターン

• OGP の仕組み: ページの title・画像・説明等を HTML の タグで外部に公開する仕様
• CORS の制約: ブラウザは異なるオリジンへの fetch レスポンスを JavaScript からブロックする。Access-Control-Allow-Origin: * が設定されていないサイトが多い
• 解決策: CORS Proxy を経由して HTML を取得する
  • corsproxy.io などのプロキシサービスを使用
  • URL: https://corsproxy.io/?${encodeURIComponent(targetUrl)}
• パース手順:
  1. fetch で HTML テキストを取得
  2. new DOMParser().parseFromString(html, ’text/html’) で DOM 化
  3. dom.head.children を filter/map して og: プレフィックスの meta を抽出
• Twitter Card の取得: name 属性が “twitter:” で始まる meta タグを同様に抽出
• 注意点: キャッシュや文字コードの考慮が本番実装では必要（補足としてコード例が別途ある）

GitHub リポジトリの更新を Nostr へ通知する

• URL: https://zenn.dev/snowcait/articles/e0b473c69f2859
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitHub Actions の on トリガーと jobs の if 条件を組み合わせ、Pull Request がマージされたタイミングで Nostr へ通知を送るワークフローを構築できる。snow-actions/nostr アクションを使うことで、リレーサーバーと秘密鍵を設定するだけで NIP-01 kind 1 の通常投稿が可能になる。さらに NIP-38 kind 30315 を使うとユーザーステータスも更新でき、有効期限を 12 時間に設定するといった細かい制御もできる。リレーアドレスはリポジトリ変数、秘密鍵はシークレットとして管理するパターンが示されている。

詳細

通常投稿（NIP-01 kind 1）の設定:

• uses: snow-actions/nostr@v1.6.0 with: relays: ${{ vars.NOSTR_RELAYS }} private-key: ${{ secrets.NOSTR_PRIVATE_KEY }} content: | PR タイトルと URL を含む投稿文

ユーザーステータス更新（NIP-38 kind 30315）:

• kind: 30315 を指定
• tags に d・t・r・expiration を設定
• expiration には date コマンドで 12 時間後の UNIX タイムスタンプを算出して渡す

トリガー条件:

• on: pull_request のイベント
• if: ${{ github.event.pull_request.merged == true }} でマージ時のみ実行

ハッシュタグが不要な場合は tags フィールドごと省略できる。

Nostr で認証バッジを付ける

• URL: https://zenn.dev/snowcait/articles/e2361b3827d517
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Nostr は分散型 SNS プロトコルで、公開鍵・秘密鍵ベースのアカウント管理を採用し、メール登録不要でアカウントを作成できる。NIP-05 仕様に基づき DNS を使った認証バッジを取得でき、自分のドメインに /.well-known/nostr.json を公開することで設定できる。自前サーバーがなくても GitHub Pages を使って無料でホストする方法があり、GitHub アカウントで運用すれば一定の本人確認としても機能する。Jekyll が隠しフォルダをホストしない点に注意が必要で、.nojekyll ファイルの作成が必須となる。CORS 設定も必要だが GitHub Pages はデフォルトでワイルドカードを許可している。

詳細

Nostr の基本:

• 公開鍵・秘密鍵でアカウント管理。メール登録不要
• リレーサーバー経由でデータを中継。複数リレーへ接続して冗長化
• 秘密鍵漏洩時の復旧手段なし。通信量が多い点に注意

GitHub Pages を使った NIP-05 認証バッジの設定手順:

1. {USERNAME}.github.io という名前のリポジトリを作成
2. /docs/.nojekyll を作成（Jekyll の隠しフォルダ除外を無効化）
3. /docs/.well-known/nostr.json を作成: {“names”: {“ユーザー名”: “Hex公開鍵”}}
4. Settings > Pages で /docs をホストソースに設定
5. クライアントのプロフィール NIP-05 欄に {username}@{username}.github.io を設定

ユーザー名を _ にするとドメインだけの表示になる。 Hex 公開鍵は Iris の場合アカウント設定の Copy hex で取得可能。

動的サーバーを使う場合: クライアントは name クエリパラメーターを付けてアクセスするため、指定ユーザーのデータのみ返すよう実装すると効率的。Access-Control-Allow-Origin: * の CORS 設定が必要。

Nostr のプロフィールを GitHub リポジトリで管理する

• URL: https://zenn.dev/snowcait/articles/ed618cf8514fce
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Nostr BOT のプロフィール（kind 0 イベント）を GitHub リポジトリで管理し、metadata.json の更新をトリガーに GitHub Actions で自動配信する方法を解説した記事。snow-actions/nostr アクションを使い、秘密鍵は GitHub Secrets で保管する構成で、リレーリストも JSON で Git 管理できる。kind 0 以外のイベントにも応用でき、Nostr クライアントを使わずに BOT をすべて GitHub Actions で管理する運用パターンとして有用。

詳細

Nostr プロフィールを GitHub Actions で自動管理するワークフロー設計

• アプローチ: metadata.json（kind 0 content）をリポジトリにコミットし、main ブランチへの push でワークフローを自動起動
• 使用アクション: snow-actions/nostr@v1.7.0（kind・content・relays・private-key を指定）
• 秘密鍵の管理: GitHub Secrets に NOSTR_PRIVATE_KEY として保存
• トリガー設定: paths: [metadata.json] で metadata.json 変更時のみ実行（ワークフローファイル自身は除外）。workflow_dispatch で手動起動も可能
• リレーリストの Git 管理:
  • relays.json で管理 → jq -c -r ‘.[]’ で1行ずつ出力して relays に渡す
• 送信イベントをリポジトリにコミットする方法:
  • permissions: contents: write が必要
  • snow-actions/nostr に id を付与し、outputs.event を jq で整形して docs/metadata.json へコミット
• 応用範囲: kind 0 以外（投稿・リアクション等）にも使用可能。Nostr クライアント不要で BOT 全体を GitHub で管理できる

「なぜ肌が良くなったのか」を答えられるか — YouCam API×Claude AIで作るBeauty Research OS

• URL: https://zenn.dev/taka4/articles/607a211fe7db7b
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: YouCam API（Perfect Corp社）で肌を数値化し、Apple Healthの睡眠データと掛け合わせてClaude AIが週次で相関を分析するBeauty Research OSのコンセプト実装記事。Pearson相関係数の計算はPython側で行い、AIは解釈のみに専念させる設計でテスタビリティと再現性を確保している。毎朝のデイリーノートをYAML frontmatterで構造化してObsidianに蓄積し、DataviewプラグインでSQLライクに問い合わせることで、「なぜ肌が改善したか」を追跡できる知識複利の仕組みが示されている。

詳細

YouCam API（Perfect Corp社）とApple Health、Claude AIを組み合わせてスキンケアの因果関係を追跡するBeauty Research OSのアーキテクチャと実装解説。

• YouCam APIは4段階非同期フロー：POST /s2s/v2.0/file/skin-analysis（presigned URL取得）→PUT S3（画像アップロード）→POST /s2s/v2.0/task/skin-analysis（タスク作成）→GET でポーリング
• 取得指標：dark_circle_v2、pore、wrinkle、texture（各ui_score）とall（総合スコア）、skin_age
• Apple Health export.xmlのパース：HKCategoryTypeIdentifierSleepAnalysis（値がAsleepのレコード）の時刻は空白区切り→.replace(" “, “T”, 1)でISO 8601に変換してタイムゾーン保持
• Pearson相関係数はPython側で計算し、AIは解釈のみに専念させる設計でテスタビリティを確保
• ObsidianデイリーノートをYAML frontmatterで構造化し、Dataviewプラグインで睡眠×肌スコアの相関をSQLライクにクエリ
• 週次レビューでは「睡眠7時間以上の週はくまスコアが改善する」などの法則が蓄積されていく知識複利設計

[Claude Desktop] Chat・Cowork・Codeの違いや使い分けを整理

• URL: https://zenn.dev/taka4/articles/8bc72d18bb9d2e
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude DesktopのChat・Cowork・Codeの3タブの機能差異と使い分けを体系的に整理した解説記事。実行レイヤー・サンドボックス・メモリシステムが3タブで異なることを明確にしており、ChatのArtifacts（静的）とCoworkのLive Artifacts（動的）、CoworkのScheduled（ローカルPC依存）とCodeのRoutines（クラウド実行）などの対比も具体的に示されている。Proプランで使える機能や使用量の仕組み、2026年5月に5時間レート制限が2倍になった変更点なども網羅している。

詳細

Claude Desktop（macOS・Windows向け公式アプリ）のChat・Cowork・Code 3タブの機能差異を比較整理した解説記事。2026年6月更新。

• Chat：ブラウザ版claude.aiと同等の会話機能。Projects（クラウド保存・チーム共有）、Artifacts（静的プレビュー）、Instructions/Styles/Skills設定
• Cowork：ローカルPC上でファイル操作・外部サービス書き込み・マルチステップタスクを実行。VM内でコードを隔離実行。Scheduled（PC起動中のみ）、Live Artifacts（コネクターから最新データ動的取得）、Dispatch（モバイル→デスクトップへの非同期タスク委任）
• Code：Claude Code CLIをGUI化。Node.jsやCLI別途インストール不要（同梱）。Routines（クラウド実行でPC OFF時も動作）、PR自動レビューや依存関係監査に活用可能
• プラン差異：無料はChatのみ。Pro/MaxでCowork・Code利用可能
• 使用量：Chat・Cowork・Code共通プールから消費。2026年5月に5時間レート制限が2倍に引き上げられピーク時制限も撤廃
• Claude Design（2026年4月リリース）は3タブとは独立した別プロダクトで使用量クォータも別枠管理

56本 → 5本、88%削減 — TiDB FTS+Vectorで作るAbility Discovery Layer

• URL: https://zenn.dev/taka4/articles/fb3809bc7e4a82
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: AIエージェントが保有するMCPサーバー・スキルが56本に増えた際のTool Explosion問題を解決するAbility Discovery Layerの実装記事。TiDB CloudのFTS（全文検索）とVector Hybrid Searchを組み合わせ、ユーザーのクエリに応じて必要なツールをTop-5本に絞り込むことでトークン消費を平均88%削減した。日本語クエリの精度改善にはLLMによるQuery Expansionを使い英語キーワードを付与する手法を採用し、nomic-embed-textのベクトル検索精度が大幅に向上することを実証している。

詳細

MCPサーバー・スキルが56本に増加した環境でのTool Explosion問題を解消するAbility Discovery Layerの設計と実装。TypeScript + Node.js 22 + TiDB Cloud Serverless（ap-northeast-1）+ Ollama構成。

• 問題の規模：全56本のツール説明テキストで約2,258トークン消費。関係のないツールがコンテキストを圧迫し精度も低下
• 解決策：discover_toolsを1回呼ぶだけでTop-5本を取得。トークン消費2,318→約279（88%削減）、ツール数56→5（91%削減）
• スキーマ設計：search_text Generated Column（name + descriptionの結合）にFULLTEXT INDEX（MULTILINGUAL）とVECTOR INDEXを共存
• FTS検索：TiDB CloudのFTS_MATCH_WORD()はWHERE句で単独使用が必要（WHERE FTS_MATCH_WORD() > 0はエラー）
• Vector検索：Ollama + nomic-embed-text（768次元）でVEC_COSINE_DISTANCEを使用
• Query Expansion：日本語クエリをqwen3:14bで英語キーワードに展開することでベクトル検索精度が大幅改善（Vector距離が密集する問題を解消）
• mem9 Boost：個人利用履歴でTop-5のパーソナライズも実現

GitHub Actions で GitHub Models を使って terraform plan の実行結果を要約してもらう

• URL: https://zenn.dev/terraform_jp/articles/gha-terraform-plan-summarize
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitHub Actions の GITHUB_TOKEN で利用できるようになった GitHub Models を活用し、terraform plan の実行結果を自動要約して Pull Request にコメントするワークフローの実装例を紹介している。actions/ai-inference アクションに model と system-prompt を渡すだけで利用でき、モデルには openai/gpt-4o などを指定できる。models: read 権限の付与が必要で、現時点では無料利用可能ながらモデルごとのレート制限がある。

詳細

ワークフローの構成（4 ステップ）:

1. セットアップ: actions/checkout、hashicorp/setup-terraform
2. terraform init + terraform plan を実行し、ANSI エスケープシーケンスを sed で除去して GITHUB_OUTPUT に設定
3. actions/ai-inference@v1 で GitHub Models を呼び出して要約生成（model: openai/gpt-4o、max-tokens: 4000、system-prompt に日本語での要約フォーマット指示）
4. peter-evans/find-comment + peter-evans/create-or-update-comment で PR コメントを作成または更新（同一 PR での二重コメント防止）

必要な permissions:

• contents: read
• models: read — GitHub Models 利用に必須
• pull-requests: write — PR コメント作成に必須

補足:

• ANSI エスケープシーケンス除去の理由: terraform plan 出力に色付きのエスケープシーケンスが含まれるため LLM への渡し前に除去が必要
• HCP Terraform 利用者向けには公式 Terraform Plan Analyzer モジュールが別途存在する
• actions/ai-inference の REST API は無料だがレート制限あり（モデルごとに異なる）

【Terraform】AWS Provider v6 からはリソースレベルでリージョンを設定できる

• URL: https://zenn.dev/terraform_jp/articles/tf-aws-v6-per-resource-region
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Terraform AWS Provider v6 beta では、リソース定義に region 属性を直接記述できるようになり、複数リージョンを扱うために provider を複数定義する必要がなくなった。単一 provider 定義のまま for_each と region 属性を組み合わせることで複数リージョンへの動的なリソース作成も可能になる。resource・data source・ephemeral resource の各ブロックで region 属性が使え、import 時は vpc-00000000@us-east-1 のように末尾に @<region> を付加する形式で指定する。beta 期間は 6 週間で、その間にフィードバックを収集しながら正式リリースへ向けて改善が進められる。

詳細

検証バージョン: Terraform AWS Provider v6.0.0-beta1

従来（v5 以前）の問題:

• 異なるリージョンにリソースを作成するにはリージョンごとに provider を alias で定義し、各リソースの provider 属性で明示的に指定する必要があった
• provider に対して for_each が使えないため、複数リージョンへの動的なリソース作成が困難だった

v6 での変更点:

• resource、data、ephemeral ブロックに region 属性が追加された
• region を省略した場合は provider に設定されたリージョンがそのまま適用される
• region は単なる属性なので for_each と組み合わせて動的に複数リージョンへリソースを作成できる

import における region 指定:

• terraform import aws_vpc.example vpc-00000000@us-east-1
• import ブロックでは id = "vpc-00000000@us-east-1" の形式

設計上の意図（公式コメントより）:

• 複数 provider インスタンスのロードを減らしてメモリ使用量を削減する
• provider に for_each を持たせるのではなく、単一 provider 定義で完結させる設計方針

一部のメタデータリソースやグローバルリソースには region 属性を設定できない（公式ドキュメント参照）。 v5 から v6 へのアップグレードガイドには破壊的変更が含まれるため事前確認が必要。

【Terraform 1.14】terraform query コマンドで既存リソースを一括 import する

• URL: https://zenn.dev/terraform_jp/articles/tf-query-bulk-import
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Terraform v1.14.0 beta に追加された terraform query コマンドを使うと、.tfquery.hcl ファイルに list ブロックを記述するだけで Terraform 管理外の既存リソースを一覧取得できる。-generate-config-out フラグと組み合わせると、取得したリソースに対応する resource ブロックと import ブロックが自動生成される。あとは terraform apply を実行するだけで一括 import が完了する。config ブロックで特定タグによるフィルタリングも可能で、terraformer のような外部ツールに頼らず公式コマンドで同等の操作が行えるようになる。

詳細

検証環境: Terraform v1.14.0-beta1、AWS Provider v6.14.0

List Resources の使い方:

• .tfquery.hcl ファイルを作成し list ブロックを記述する
• provider 属性は必須
• config ブロックでプロバイダ固有の引数（フィルタなど）を指定できる
• include_resource で全属性取得、limit で取得上限を指定（デフォルト 100）

terraform query コマンドの実行例:

• terraform query で一覧表示
• terraform query -generate-config-out=generated.tf で resource ブロックと import ブロックを自動生成
• 生成後に terraform apply を実行するとリソースが Terraform 管理下に移行する

実用上の意義:

• 従来 googlecloudplatform/terraformer などのサードパーティツールが担っていた「既存リソースの一括 import」が公式コマンドで実現できるようになる
• for_each 不可などの制約がある旧来の import 作業が大幅に自動化される

Terraform v1.11 の Write-Only Attributes を試してみる

• URL: https://zenn.dev/terraform_jp/articles/tf-write-only-attributes
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Terraform v1.11 で導入された Write-Only Attributes は、tfstate に値を保存しない書き込み専用の属性であり、機密情報の平文漏洩という長年の課題を解消する。aws_ssm_parameter の value_wo を使うと、パスワード等の秘密値が apply 後の tfstate に残らないことを実際の出力で確認できる。変更を検知するには value_wo_version を一緒に更新する必要があり、その数値は任意の整数で構わない。Terraform Provider 側の実装次第でインターフェースが変わるため、他リソースでの採用状況は今後の動向を追う必要がある。

詳細

Terraform v1.11 の Write-Only Attributes とその動作検証

• 従来の sensitive 属性: plan/apply 時の表示はマスクされるが、tfstate には平文で保存されてしまう
• Write-Only Attributes: tfstate に値が保存されない書き込み専用属性。aws_ssm_parameter では value の代わりに value_wo を使用する
• plan 出力では (write-only attribute) と表示され、apply 後の tfstate では value_wo: null、value: "" となる（実際にSSMパラメータには正しく設定される）
• 変更検知の仕組み: value_wo_version という整数フィールドを一緒に更新しないと No changes. と判断される。数値は任意（0、負値でも動作）
• 検証環境: Terraform v1.11.0-beta2 + AWS Provider v5.87.0（2025/02/14リリース）
• 制約: 属性名の命名規則（_wo / _wo_version）はリソースごとに異なる場合があり、Provider 実装依存
• 関連機能: Terraform v1.10 の Ephemeral resources/values とあわせ、state に値を保存しないための機能が充実しつつある

バックエンドもフロントエンドもインフラも Terraform でつくってみた

• URL: https://zenn.dev/terraform_jp/articles/tftftf-introduction
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Terraform の HCL でアプリケーション全体（バックエンド・フロントエンド・インフラ）を実装するという実験的試みの紹介記事。バックエンドには JS.tf（HCL で JavaScript を記述するツール）、フロントエンドには HTML.tf（HCL で HTML を記述するツール）という独自プロバイダを使用している。著者自身が「二度とやりません」と締めくくるほど実用性より挑戦色が強い内容だが、HCL の表現力の限界を探るユニークな試みとして記録に値する。

詳細

Terraform だけでアプリケーション全層を構築する実験

• 動機: Terraform Advent Calendar 2024（9日目）の記事。HCL だけでアプリを完結させる極端な実験
• 使用技術:
  • バックエンド: JS.tf（HCLでJavaScriptプログラムを記述 → local_file リソースでファイル出力）
  • フロントエンド: HTML.tf（HCLでHTMLを記述 → local_file リソースで出力）
  • インフラ: 通常の AWS Provider
• HCL でコード生成するアプローチで、実質的にはコード生成ツールをTerraformのデータソースとして扱っている
• 著者の総評: 「二度とやりません（めちゃくちゃ大変だった）」
• 教訓として示されているポイント: “アプリと同じ言語でインフラを構築する” ではなく “インフラと同じ言語でアプリを実装する” という逆転の発想
• 実用性より HCL の可能性の限界検証に近い性格の記事

Claude Code × Unity CLI Loop でチュートリアルのE2Eテストを自動化してみた

• URL: https://zenn.dev/unsoluble_sugar/articles/2a1f9e08ac9980
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude CodeとUnity CLI Loopを使い、モバイルカジュアルRPGの初回起動チュートリアル全体をE2Eテスト自動化した実践報告。当初はAIが毎ステップ状態を取得して判断するインタラクティブ方式で実装したが、トークン消費が激しく実行時間が長く再現性が低いという3つの問題が発生した。テストロジックをシェルスクリプトに固めてAIの役割をシナリオ読み込みとスクリプト実行のみに絞ることで、メインループの実行時間が240秒から104秒に短縮され入力トークンも約17000〜20000程度に抑えられた。CLI呼び出しのオーバーヘッド（1〜2秒/回）をさらに削減するため、DontDestroyOnLoadなBridge GameObjectの子オブジェクト名にゲーム内ポーリング結果を書き込む「状態ブリッジ方式」を導入し、オーバーヘッドを57%削減した。

詳細

テスト対象と背景

• モバイル向けカジュアルRPGの初回起動チュートリアル（コイン獲得・バトル・装備獲得・仲間救出・強化・装備交換を含む）
• 1回通すのに数分かかり、コード変更のたびの手動確認がコスト高
• セーブデータリセットで毎回同じ状態から開始できるため再現性確保が容易

4層アーキテクチャ

• Claude Code Skill: シナリオ読み込み・スクリプト実行順制御・結果判定・レポート生成のみ
• シェルスクリプト: テストフロー制御（ループ・sleep・リトライ）を決定論的に実装
• unity-cli-loop: Unity Editorへの命令送信（execute-dynamic-codeでC#を動的実行）
• Unity内C#: ボタンクリック・状態検知・ブリッジ書き込み

AI判断方式からの転換

• 当初のAI判断方式の問題: トークン消費大・実行時間長（240秒）・AIの判断ブレによる再現性低下
• 転換後: テストロジックをシェルスクリプトに固定、AIはbash実行とレポートのみ
• 改善結果: メインループ240秒 → 104秒、入力トークン約17000〜20000で安定

UI操作アプローチ

• 決め打ち方式（今回採用）: GameObject.Find("ボタン名") + onClick.Invoke() で名前指定クリック
• 再現性・速度・コストの面でフローが固定されたテストには決め打ち方式が適切
• AI自律判断方式: UI変更が頻繁な探索的テストに向く

状態ブリッジ方式（CLIオーバーヘッド57%削減）

• 問題: unity-cli-loop 1回呼び出しに1〜2秒かかる
• 解決: DontDestroyOnLoadなBridge GameObjectをバッファとして使用、ゲーム内で非同期ポーリングした結果を子オブジェクトの名前として書き込む
• なぜ子オブジェクト名か: execute-dynamic-codeは独立コンテキストで評価されstatic変数を跨げないが、GameObject.FindはシーンオブジェクトをCLI呼び出しをまたいで読み書きできる

その他の技術的工夫

• poll_and_click: 固定sleepではなくボタン出現までポーリング（遷移完了を検知して即実行）
• ゲーム内時間基準の遅延: bash側のsleepではなくUniTask + Time.timeでゲーム内時間を基準に処理
• セーブデータのバックアップ・復元で開発中データを保護

『実践Claude Code入門』を読みながらDev Container環境でClaude Codeを動かしてみた

• URL: https://zenn.dev/unsoluble_sugar/articles/4878a6d01b7305
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 書籍『実践Claude Code入門』第2章を元に、Dev Container（macOS + VSCode + Docker）環境でClaude Codeをセットアップした手順の記録。インストールからアカウント認証、ヘッドレスモードでのJSON出力確認まで実際のコマンド出力を交えて紹介されている。ローカル環境を汚さずにClaude Codeを試せるDev Containerのメリットが実証されており、社内での利用検討段階の読者への参考になる内容となっている。

詳細

書籍『実践Claude Code入門』第2章に基づいたDev Container環境構築の手順記録。macOS Sequoia 15.7.4 + VSCode + Docker Desktopが前提。

• テンプレートリポジトリをクローン後、Dev Containers拡張機能で「Reopen in Container」を実行してコンテナ起動
• Claude Codeのインストールはcurl -fsSL https://claude.ai/install.sh | bashで行い、バージョン2.1.63を確認
• 初期設定フロー：テーマ選択→アカウント認証→セキュリティ確認→Terminalセットアップ→フォルダ信頼確認→拡張機能インストール
• ヘッドレスモード（-pオプション）でJSON形式レスポンスの取得を確認：–output-format stream-jsonで構造化出力
• claude-opus-4-6モデルで動作することをJSON出力のmodelフィールドから確認
• Tartを使った仮想マシン環境より圧倒的に手軽とコメント。続く第3章MCP、第4章スペック駆動開発、第5章Claude Code Actionへの橋渡し記事

GitHub Actionsの自動実行がコケた朝にやったこと

• URL: https://zenn.dev/unsoluble_sugar/articles/61282957bf4b1a
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: GitHub Actionsの定期ジョブが「All jobs were cancelled」という情報の薄いエラーで失敗した際の切り分け手順を時系列にまとめた記事。公式X(@githubstatus)とインシデントページを最初に確認し、hosted runner側の障害であることを特定した流れが紹介されている。復旧待ちの時間を使ってconcurrencyを追加し、キュー滞留時の二次災害を防ぐ設定も実施した実践的な内容となっている。

詳細

毎朝の自動ニュース収集GitHub Actionsが「All jobs were cancelled」で失敗した際のデバッグと対策の記録。Feb 02, 2026 19:03 UTC発生のインシデント。

• エラーがstepログに到達していない（hosted runner取得前に失敗する）パターンを経験則から「外側の問題」と推定
• 公式X（@githubstatus）で同時間帯のアナウンスを確認 → GitHub Status（incidents/xwn6hjps36ty）でhosted runner高待機時間の問題が判明
• Feb 03, 2026 00:56 UTCに復旧確認後、Re-runで正常完了
• 復旧待ち中に追加したconcurrency設定：group: ${{ github.workflow }}-${{ github.ref }}、cancel-in-progress: trueで最新runだけ通す運用に変更
• 学習ポイント：ログが薄い（1行・stepに未到達）場合は手元の設定をいじる前に公式アナウンスと他エンジニアの報告を確認するのが先手

Claude CodeにZennリポジトリを分析させて記事作成過程をまとめてもらった

• URL: https://zenn.dev/unsoluble_sugar/articles/ae877f07fa46df
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Claude CodeにZennリポジトリ（47記事）を分析させてCLAUDE.mdを自動生成し、さらにその体験自体を記事化するというメタ体験を記録した記事。/initコマンドでリポジトリ構造・CLIコマンド・文体パターンを自動抽出したのち、Topicsの5件制限エラーをリアルタイムで検知してCLAUDE.mdにルール追記するという自律的な改善サイクルが観察された。さらにGemini CLIによる第三者レビューも実施し、Claude Code生成文とのハイブリッドでブラッシュアップする三段階のワークフローが紹介されている。

詳細

Claude Code 1.0.35でZennリポジトリ（47記事）を分析してCLAUDE.mdを自動生成し、さらにその体験を同一セッション内で記事化した記録。macOS Sequoia 15.5環境。

• /initコマンドで分析：ディレクトリ構造確認→設定ファイル確認→記事サンプル分析→Zenn CLIコマンド（npx zenn preview/new:article等）の調査
• 生成されたCLAUDE.mdの内容：リポジトリ概要、主要コマンド、コンテンツ構造（articlesのハッシュベースファイル名）、Front Matterルール（最大5トピック制限）、開発ワークフロー
• 47記事のカテゴリ分析：開発環境・ツール設定（最多）、Unity・ゲーム開発、GitHub・Git関連、Web開発、インフラ、AI・新技術
• 文体特徴の抽出：丁寧語ベース、適度なカジュアルさ（「やったぜ」「ぶっちゃけ」）、実践的なトラブルシューティング
• Topics制限エラー（6個指定→5個に修正）発生時にCLAUDE.mdへのルール追記を自律的に実施
• Gemini CLIによる追加レビュー後、文体の口語化と構成重複の整理を実施した三段階のブラッシュアップ体験

「あとで読む（読まない）」を仕組みで解決する — AI駆動の個人開発記

• URL: https://zenn.dev/unsoluble_sugar/articles/beaac7bbf9ee7a
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Raindrop.ioに溜まる「あとで読む記事」を読まないまま埋もれさせる問題を、ChatGPTで仕様書を策定しClaude Codeで実装するという仕様駆動開発で解消した個人ツール開発記録。ツールはRaindrop.ioのAPIで記事を取得し本文抽出してAI要約し、high/medium/lowの優先度付きHTMLダッシュボードとして出力するもので、Python + JSON永続化 + Jinja2 + GitHub Pages構成。CLAUDE.mdをエントリポイントとして最小限に保ち、詳細をSkill・Rules・.steering/の4層に分離するコンテキスト設計と、コード変更後に関連仕様書の乖離を検出する/update-specsカスタムスキルが特徴的だった。コードの実装のみならず仕様ドキュメント整備・Issue/PR作成・セキュリティ監査・Git履歴書き換え・リリースノート整備まで全工程をClaude Codeで完結した。

詳細

ツールの概要（Tsuyu-mi）

• 目的: Raindrop.ioの「あとで読む」記事を一次判定できる状態にする
• 優先度: high（今読むべき）/ medium（後回し）/ low（捨ててよい）の3段階をAIが判定
• 出力: HTML一覧ダッシュボード
• スコープ外: 動画コンテンツ・複数コレクション横断・DB・Web UIからの編集・Playwright等

技術スタック

• Python 3.11+ / httpx / pydantic / trafilatura / readability-lxml / jinja2 / click / rich
• JSON永続化（記事単位）、HTML主出力
• GitHub Actions + GitHub Pages で自動運用

仕様策定プロセス

• ChatGPTで仕様書の骨格を整理 → Claude Codeに実装依頼
• 実装前に8つの仕様書をdocs/specs/に配置する仕様駆動開発アプローチ

CLAUDE.md 4層設計

• CLAUDE.md: エントリポイントとして最小限（プロジェクト概要・コマンド・ドキュメント所在のみ）
• .claude/rules/: 詳細ルール（自動読み込み）
• .steering/: アーキテクチャ・設計方針
• docs/specs/: 機能仕様書8ファイル

/update-specs カスタムスキル

• コード変更後に git diff --name-only HEAD で変更ファイルを特定
• 関連する仕様書（ファイル→仕様書の対応表で特定）を読み込み、乖離を検出
• リネーム・削除があった場合、全ドキュメント内の旧パス残留を検出
• README.md・CLAUDE.md・.steering/の更新要否も確認

Claude Codeが担当した作業範囲

• 仕様ドキュメント整備・Skill/Rules作成・技術選定相談
• Issue起票・ブランチ作成・PR説明文記述
• サービス命名とリポジトリリネーム一括反映
• README（英語版・日本語版）作成・バッジ追加
• セキュリティ監査・GitHub Ruleset設定（ブランチ保護）
• 機密データのGit履歴完全削除
• v1.0.0リリースノート整備

『実践Claude Code入門』を読みながらDev Container環境でPlaywright MCPを動かしてみた

• URL: https://zenn.dev/unsoluble_sugar/articles/c1002e60e2fb8b
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 書籍『実践Claude Code入門』第3章を参照しながら、Dev Container環境でPlaywright MCPを動かした手順を記録した実践記事。Chromiumの未インストールや日本語フォント欠如などのエラーをClaude Codeが自律的に検知・修正しながら進む様子が紹介されている。ブラウザ操作、スクロール、スクリーンショット取得まで自然言語で指示できることが確認され、簡易E2Eテストへの応用可能性も示唆されている。

詳細

Dev Container環境でPlaywright MCPを動かした手順記録。書籍『実践Claude Code入門』第3章のハンズオン。

• .devcontainer/.mcp.jsonにPlaywright MCPサーバーを定義し、Claude Code起動時に有効化するとsettings.local.jsonに設定が保存される
• 初回実行でChromiumが未インストールのエラーが発生したが、Claude Codeが自動でインストール処理を進めた
• Dev Container環境に日本語フォントがなくスクリーンショットが文字化けしたため、fonts-noto-cjkとfonts-ipafont/fonts-ipaexfontをインストールして解消
• ページ遷移・要素クリック・JavaScriptスクロール・スクリーンショット取得を自然言語の指示で実行できることを確認
• 簡易E2Eテストへの応用が現実的な範囲で可能と著者が評価
• 書籍で紹介されているMCPサーバー：Context7 MCP（最新ドキュメント提供）、Serena MCP（コーディングエージェントツールキット）

Claude Code経由でのGitHub PR作成時に自動でassigneeとlabelを設定する方法

• URL: https://zenn.dev/unsoluble_sugar/articles/c3f6e223b60bcd
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: CLAUDE.mdのPull Request Workflowセクションにgh pr create -a {ユーザー名} -l {ラベル}を明記するだけで、Claude Code経由のPR作成時にassigneeとlabelが自動設定できることを実践例で示した記事。-aオプションで複数のassignee指定、-lオプションで複数ラベルの付与、–body-fileオプションでのテンプレート参照なども紹介されている。CLAUDE.mdに自然言語でワークフローを定義するだけでClaude Codeの動作を統制できるシンプルな仕組みが確認できる。

詳細

CLAUDE.mdのPull Request Workflowセクションを更新してClaude Code経由のPR作成時にassignee・labelを自動設定する方法の実践記事。

• gh pr createの-a（–assignee）と-l（–label）オプションをCLAUDE.mdに直接記載することで自動化を実現
• 基本コマンド例：gh pr create -a unsolublesugar -l enhancement –title “タイトル” –body “本文”
• 複数label：-lオプションを複数回使用（-l enhancement -l documentation）
• 複数assignee：-aオプションを複数指定（-a user1 -a user2）
• 条件分岐：バグ修正/新機能/ドキュメントごとに異なるコマンドをCLAUDE.mdに記載可能
• PRテンプレート活用：–body-file .github/pull_request_template.mdとの組み合わせ
• ドラフトPR：–draftオプション追加で作業中PRの管理も可能

uLoopMCP × Claude Code、AI駆動でUnityゲーム開発がどこまで自走できるか試してみた

• URL: https://zenn.dev/unsoluble_sugar/articles/cd8d59be7b8f85
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: uLoopMCPというMCPサーバーを使い、Claude CodeからUnity Editorを直接操作してブロック崩しゲームを自律開発する実験記事。コンパイル、Scene構築、Play実行、スクリーンショット確認というサイクルをClaude Codeが人間の介入なしで繰り返す様子が紹介されている。Plan modeによる仕様策定から始まり、uLoopMCPが提供する/uloop-compile、/uloop-capture-windowなどのスキルを組み合わせた開発フローが体験ベースで解説されている。

詳細

uLoopMCP（io.github.hatayama.uloopmcp）を使ってClaude CodeからUnity 6 LTSプロジェクトを制御し、2Dブロック崩しゲームを自律的に開発した実験記録。

• uLoopMCPの主要スキル：/uloop-compile（コンパイル・エラー検出）、/uloop-run-tests、/uloop-get-hierarchy（Hierarchy構造取得）、/uloop-capture-window（EditorWindowキャプチャ）、/uloop-execute-dynamic-code（C#コード動的実行）
• セットアップ：OpenUPMスコープにio.github.hatayama.uloopmcpを登録、Microsoft.CodeAnalysis.CSharpをインストール、uLoopMCPパネルでClaudeを選択しセキュリティレベルをRestrictedに設定
• Plan modeで7ファイル構成の仕様書（GameConstants/GameManager/BallLauncher/Ball/Block/BlockManager/UIManager）を策定してから実装に移行
• 自律開発サイクル：スクリプト生成→compile→PlayMode起動→capture-windowでスクリーンショット確認→コード修正→再compile
• 特に/uloop-get-hierarchyでScene構造を把握しつつ/uloop-capture-windowで画面確認できるため的外れな修正が減少と評価

Unity 6でFacebook SDK導入後、Androidビルドがフリーズした原因とEDM4U運用の注意点

• URL: https://zenn.dev/unsoluble_sugar/articles/f13714fe999f54
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: Unity 6にFacebook SDK 18.0.0を導入後、Androidビルドがフリーズした問題の原因特定と対処をまとめた記事。表面的なエラーメッセージ「Java Runtimeが見つからない」はミスリーディングであり、実際の原因はFacebook SDK同梱の古いEDM4U（v1.2.166）が使用するGradle 5.1.1がUnity 6のJava 17環境で初期化に失敗していたことと分かった。解決策はSDKに同梱されたEDM4Uを削除し、プロジェクト側で最新版（v1.2.186）を一元管理することで、複数SDK導入時のEDM4U競合を防ぐベストプラクティスが示されている。

詳細

Unity 6（6000.0.62f1）+ Facebook SDK 18.0.0導入後のAndroidビルドフリーズ問題の原因分析と解決策。macOS Sequoia 15.6.1環境。

• 初期エラー「Unable to locate a Java Runtime」はミスリーディング。実際の原因はEDM4UのGradle/Groovy初期化失敗
• Examplesフォルダ削除でログが変化し、java.lang.NoClassDefFoundError（org.codehaus.groovy.vmplugin.v7.Java7）が顕在化して真因が判明
• バージョン構成の問題点：Unity 6はJava 17（OpenJDK 17）を使用するが、Facebook SDK 18.0.0同梱のEDM4U v1.2.166が内部で使うGradle 5.1.1はJava 17非対応（Gradle 7.3以降が必要）
• 注意：v1.2.186（2025年5月）やv1.2.187（2026年1月）でもGradle Wrapperは5.1.1のままで根本解決していない
• 対処：Facebook SDK同梱EDM4U/PlayServicesResolverを削除、最新版EDM4U v1.2.186をプロジェクト側で一元管理してForce Resolve
• 複数SDK導入時のベストプラクティス：各SDKのバンドルEDM4Uは使わず、ThirdParty/ExternalDependencyManager/に最新版1本を置いて全SDK共通で参照する