AWSのPhysical AI Scaffolding Kit (PASK)を試す① — SageMaker HyperPodでSlurmクラスタを構築する

• URL: https://dev.classmethod.jp/articles/try-aws-pask-01-build-slurm-cluster-with-hyperpod/
• 日付: 2026-06-16
• Tier: Tier 2
• 要旨: AWSのロボット学習（Physical AI）向けサンプルリポジトリ「PASK」のhyperpod/コンポーネントを使い、SageMaker HyperPodでSlurmクラスタを実際に構築した記録。CDKで16分でVPC・NAT・FSx for Lustre・HyperPodクラスタ（ml.c5.large×2）が立ち上がることを確認した。

詳細

PASKはAWS上でPhysical AIモデルのGPU学習環境を提供するCDKサンプル集。2層構成で、環境構築（hyperpod/、physai/、isaacsim-workstation/）と学習サンプル（π0/openpi、NVIDIA Isaac GR00T、Isaac Lab Newton RL）からなる。

構築手順はcdk bootstrap→cdk deploy（約16分）。デフォルトではWorkersGroupが空のためGPUワーカーなしで開始できる設計になっており、GPUインスタンス確保失敗によるデプロイ全体の失敗を防いでいる。

ログインノードへのSSH接続はAWS Session Manager（SSM）のトンネル経由で実現。easy-ssh.shスクリプトを使うが、クラスタ作成直後は公開鍵の自動登録に失敗することがあり、手動でauthorized_keysに追記する必要があった。

sinfoでSlurm稼働を確認後、FSx for Lustre（/fsx/s3link）にファイルを置くとS3バケットに自動同期されることを確認。アイドル状態でも月$355相当（1日$11〜12）の課金が発生するため、使用後はcdk destroyで破棄する運用が前提。次回はGPUワーカー追加と学習サンプル実行を予定。

累計1,500万リクエストの大量ボットにAWS WAF Monetizeで402 Payment Requiredを返してみた

• URL: https://dev.classmethod.jp/articles/aws-waf-monetize-402-large-scale-bot-15m-requests/
• 日付: 2026-06-16
• Tier: Tier 2
• 要旨: Chrome/114という2年以上前のバージョンを固定UAとし、同一JA3/JA4フィンガープリントで3IPから日次約87万リクエストを送りつけてくるボットに対し、AWS WAFのMonetize機能（402 Payment Required）をRateBasedルールと組み合わせて本番環境に適用した実録。

詳細

dev.classmethod.jp本番環境（CloudFront+WAF）で5月末から検知していたUA偽装ボット。3IPが均等に分散して日次総量がほぼ固定（0.3%以下の振れ幅）、JA3/JA4が全IP共通というパターンからレート固定の自動化アクセスと判定した。

Block/Challengeを選ばなかった理由として、JSアセット取得が確認されていたためJSチャレンジを突破するリスクがあること、IPアドレスの保有者が有名SaaS企業でありBlock前に接触・確認をしたかったこと、の2点を挙げている。

実装は二段構成。RateBasedルール（60秒/100リクエスト、Count）でラベルを付与し、そのラベルに一致するMonetizeルールが402を返す。このためMonetizeはRateBasedに直接指定できないという制約を迂回している。PriceMultiplier:10で1リクエスト0.01USDCの価格提示。今回はTESTモード/Base Sepoliaテストネットでの適用で実課金ではない。

WAFログでterminatingRuleId: Monetize-HeadlessBot、responseCodeSent: 402を確認。支払いも停止もない場合はBlockへ移行する方針。

Claude Code v2.1.178 の主要アップデート

• URL: https://dev.classmethod.jp/articles/20260616-cc-updates-v2-1-178/
• 日付: 2026-06-16
• Tier: Tier 2
• 要旨: Claude Code v2.1.178（2026年6月15日公開）の22件の変更を整理したまとめ記事。新機能としてTool(param:value)パーミッション構文とネストした.claude/skills対応が追加され、autoモードのパーミッション評価の抜け穴をふさぐセキュリティ修正が含まれる。

詳細

主な新機能は2点。Tool(param:value)構文の追加により、Agent(model:opus)のようにツールの入力パラメータ単位で許可・拒否を制御できるようになった。ネストした.claude/skills対応では、サブプロジェクトごとに異なるスキルを定義でき、名前衝突時は<dir>:<name>形式で両方を利用可能に保つ。

セキュリティ面では、autoモードでサブエージェントの起動がクラシファイアで事前評価されるようになり、ブロック対象のアクションを事前レビューなしで要求できる抜け穴が解消された。サブエージェントのdisallowedToolsでMCPサーバーレベルの指定が無言でスキップされていたバグも修正された。

不具合修正はサブエージェントのトランスクリプト表示・メッセージ破棄・ctrl+bによる再起動、認証情報リフレッシュ後の認証エラー継続、コンパクションが--fallback-modelを無視する問題、VSCode上のCJK IMEのEscキー誤操作など多数。Claude Fable 5アクセス一時停止後、6/13以降の初アップデートとなる。

Amazon CloudWatch が OpenTelemetry メトリクスをネイティブサポート（GA）— OTLP 直接送信と PromQL を試してみた

• URL: https://dev.classmethod.jp/articles/cloudwatch-otel-metrics-ga-otlp-promql/
• 日付: 2026-06-16
• Tier: Tier 2
• 要旨: Amazon CloudWatchがOpenTelemetryメトリクスのネイティブサポートをGAした。従来のPutMetricData方式（Classicモデル）に加え、OTLP直接送信とPromQLクエリが利用可能になり、高カーディナリティなワークロードではコストが大幅に削減できる場合がある。

詳細

2026年6月16日にGAとなったCloudWatch OTel Metricsは、既存のCloudWatch Metrics（Classic）とは別のストアに格納される。課金モデルが変わり、ユニークメトリクス数×月ではなくGB単位の取り込み課金になる。検証によれば5,000ユニークメトリクス・1分間隔の送信で、Classicが月$1,500超なのに対しOTelは月$54程度になるケースがある。

OTLPのエンドポイントはSigV4署名付きHTTP POSTで、cloudwatch:PutMetricData権限で送信可能。PromQLのクエリはPrometheus HTTP API互換で/api/v1/queryと/api/v1/query_rangeに対応する。

CounterとGaugeの型意味論が導入され、rate()やincrease()が意図に沿って機能するようになった。送信後約10秒でPromQLから参照可能になることを実測で確認。ただし7日間のレンジ上限や500シリーズ上限などの制約がある。Classicで高カーディナリティに悩んでいる場合やPromQLを活用したい場合に有力な選択肢となる。

DevOps Agentのメモリ機能を確認してみた

• URL: https://dev.classmethod.jp/articles/devops-agent-memories/
• 日付: 2026-06-16
• Tier: Tier 2
• 要旨: 2026年6月12日のアップデートでDevOps Agentに追加されたメモリ機能を実機確認した。monitors（過去の調査から自動学習）とdirectives（ユーザー手動入力）の2種類のManaged Memory Storeがあるが、チャット経由で作成したメモリにYAML frontmatterが付与されず調査時にエラーになるバグが現時点で存在する。

詳細

DevOps Agent Memoriesは、Agent Spaceに固有のコンテキストをMarkdownファイルとして蓄積する仕組み。SkillsやAgent Instructionsとの役割の違いは、「何をするか（手続き的）」ではなく「何を知っているか（情報的）」を補完する点にある。

monitorsストアは2週間以内の調査結果からLearning Agentが1日1回自動生成・更新し、2週間更新がないメモリは自動削除される。directivesストアはユーザーがチャット経由で手動入力する形で、社内インフラの命名規則やサービス構成などを記録できる。

チャットからdirectivesメモリを作成できたことを確認したが、作成したメモリにYAML frontmatterが付与されないため、調査トリガー時のメモリ読み込みでエラーが発生した。現時点の回避策として、チャットからメモリを参照させて調査を依頼することで環境情報を加味した根本原因を得ることができた。monitors側の自動学習については引き続き検証予定。

Foundation Modelsフレームワークでテキスト生成してみた

• URL: https://dev.classmethod.jp/articles/foundation-models-text-generation/
• 日付: 2026-06-16
• Tier: Tier 2
• 要旨: Apple WWDC25で発表されたFoundation Modelsフレームワーク（オンデバイス推論）を使い、テキスト生成・ストリーミング・システムプロンプト設定・構造化出力・マルチターン会話の5機能を実機（iPhone 16e）で検証した。

詳細

SystemLanguageModel.default.isAvailableで利用可否を確認し、LanguageModelSession()でセッションを生成。基本APIはrespond(to:)（完全なレスポンスを返す）とstreamResponse(to:)（ストリーミング）の2系統。

検証環境はXcode 27.0 Beta・macOS Tahoe 26.5.1・iPhone 16e（iOS 27.0 Beta）。同一プロンプトに対して表現が揺れることがあり、クラウドLLMと同様に確率的な挙動が確認された。

LanguageModelSession(instructions:)でシステムプロンプト的なキャラクター設定が可能で、専門用語レベルの語彙差異は確認できた。@Generableマクロを付与した構造体を型として指定すると、型制約内でガイド付き生成が行われ、自由テキスト生成より出力が安定する。

注意点として、コンテキストウィンドウがクラウドLLMより小さく、シミュレータではSensitiveContentAnalysisMLのサブモデルが欠落してエラーが出ることがある（実機で解消）。WWDC26ではAFM 3 Core Advanced（20B）とクラウド推論AFM 3 Cloud Proも発表されており、今後のAPIへの対応が期待される。

GitHub Copilot CLI のローカルサンドボックスを試してみた

• URL: https://dev.classmethod.jp/articles/shoma-trying-github-copilot-cli-local-sandbox/
• 日付: 2026-06-16
• Tier: Tier 2
• 要旨: 2026年6月2日にPublic PreviewとなったGitHub Copilot CLIのローカルサンドボックスを実機検証した。シェルコマンドの実行を隔離する仕組みであり、ファイルシステム境界・ネットワーク制御・キーチェーンアクセスの3軸で設定できることを確認した。

詳細

/sandbox enableでサンドボックスを有効化した後、/sandboxの対話UIで全般・ファイルシステム・ネットワークの3タブを設定できる。MCP/LSPサーバーもサンドボックス内で実行可能。

実機での4ケース検証結果は次のとおり。ケース1（CWD外への書き込み）は正しくブロックされた。ケース2（外部curlのブロック）はweb_fetchなどモデル組み込みツールはサンドボックス外で動作するため外部URLの取得を遮断できなかったが、明示的にcurlコマンドとして指示した場合はブロックされた。ケース3（ホスト単位allow）はmacOSのSeatbeltでは個別ホストのブロックが機能しないことを確認した。ケース4（キーチェーンアクセスOFF+git push）は想定どおり認証情報取得が拒否された。

守備範囲はあくまで「Copilotが起動するシェルコマンド」であり、内蔵ツール経由の操作はサンドボックスの境界外になる点に注意が必要。

Amazon BedrockでxAIのGrok 4.3が利用可能になったのでIAM認証で試してみた

• URL: https://dev.classmethod.jp/articles/grok-4-3-amazon-bedrock-mantle-iam/
• 日付: 2026-06-16
• Tier: Tier 2
• 要旨: xAIのGrok 4.3がAmazon Bedrockで利用可能になった。従来のBedrock RuntimeではなくOpenAI互換のbedrock-mantleエンドポイント経由で、IAM認証（SigV4）で接続できることを確認している。

詳細

Grok 4.3はxai.grok-4.3というモデルIDで、bedrock-mantleエンドポイント（https://bedrock-mantle.{Region}.api.aws/openai/v1）経由でOpenAI互換APIとして利用する。aws-bedrock-token-generatorでIAMベースのBearerトークンを生成してOpenAI SDKに渡す方式。

主なスペックは1Mトークンのコンテキストウィンドウ、Reasoning対応（effort: none/low/medium/high）、現時点ではus-west-2のみ。料金はOn-Demandで入力$1.25/1Mトークン、出力$2.50/1Mトークン。Claude Sonnet 4.6の入力$3.00、出力$15.00と比較すると出力が大幅に安い水準になっている。

日本語生成とFunction Callingを実機で確認。コンソールのモデルカタログには表示されないものの、bedrock-mantleエンドポイントへのリクエストは正常に処理されることを確認している。2026年6月16日時点でGAではなく、IAM権限やモデルアクセス設定の確認が必要な場合がある。

Googleが公開したAIエージェント向け知識共有フォーマット『OKF』を触ってみた

• URL: https://dev.classmethod.jp/articles/open-knowledge-format-okf-v01-guide/
• 日付: 2026-06-16
• Tier: Tier 2
• 要旨: Google CloudがAIエージェント向けの知識共有フォーマット「Open Knowledge Format（OKF）v0.1」を公開した。YAML フロントマター付きMarkdownファイルのディレクトリツリーで知識を表現するベンダー中立な仕様で、CLAUDE.mdやAGENTS.mdのようなアドホックな慣習を標準化しようとするものと筆者は位置づけている。

詳細

OKFの必須フィールドはtypeだけ。タイトル・説明・タグ・更新時刻などは推奨だが任意。予約ファイル名としてindex.md（ディレクトリ一覧）とlog.md（変更履歴）があり、それ以外の.mdはすべてコンセプトドキュメントとして扱われる。

筆者による実機検証では、最小バンドル（3コンセプト）を手書きして付属のビジュアライザーで可視化している。SPEC推奨の絶対パスリンクを使うとエッジが生成されない（実装がスキップしている）という不整合も発見した。Obsidian Vault 812件を検査したところ25.4%がすでにOKF v0.1準拠だったと報告している。

MCP（ライブなツールアクセス）とOKF（静的な知識表現）は競合ではなく補完関係にあり、既存のCLAUDE.md運用にtypeフィールドを追加するだけで段階的に準拠に近づけられる。v0.1はドラフト段階であり、実装と仕様のギャップは今後解消される余地がある。

OS 再起動後に SET 仮想スイッチの種類が意図せず変更される (External → Internal / Private)

• URL: https://jpwinsup.github.io/blog/2026/06/15/Hyper-V/ConfigurationAndManagement/VSwitchType-Changes-on-Reboot/
• 日付: 2026-06-16
• Tier: Tier 1
• 要旨: Windows Server 2025のHyper-VホストでSET（Switch Embedded Teaming）構成の仮想スイッチが、OS再起動後にExternalからInternalまたはPrivateに変わってしまう不具合の公式説明と対処策が公開された。

詳細

原因はHost Network Service（HNS）がOS起動時に実行する整合性確認処理の不具合。VMMS（仮想マシン管理サービス）がSET仮想スイッチの再構築を完了する前にHNSの整合性チェックが走り、HNSがSET仮想スイッチを「不整合なリソース」と誤認識して物理NICの紐づけを解除してしまう。

変更後の仮想スイッチの種類は「管理オペレーティング システムにこのネットワーク アダプターの共有を許可する」設定がONの場合はInternal、OFFの場合はPrivateになる。この影響で仮想マシンの外部接続が失われる。

対処策として指定の累積更新プログラムを適用することで解消できる。公開情報ページへの本事象の修正記載はないが、当該更新プログラムに修正が含まれていると明記されている。対象OSはWindows Server 2025のみ。

GitLab、AIエージェント向けの次世代Git互換ソースコード管理サービス「Project Switch」発表。最大で50倍高速かつ半分のトークンで利用可能に

• URL: https://www.publickey1.jp/blog/26/gitlabaigitproject_switch50.html
• 日付: 2026-06-16
• Tier: Tier 2
• 要旨: GitLabがAIエージェント向けに設計した次世代SCMサービス「Project Switch」を発表。従来のGitと互換性を持ちながら最大50倍高速、かつLLMが消費するトークン数を半減できると主張する。

詳細

body: FETCH_FAILED

GitLabが「Project Switch」を発表。AIエージェントがコードリポジトリを操作する際のパフォーマンスを最大50倍改善し、LLMトークン消費量を半分に削減することを目標としたGit互換のSCMサービス。AIエージェントによる大規模リポジトリ操作の効率化を意図した設計とみられる。記事本文の取得には失敗したため詳細の確認が必要。

AIエージェントに実行させる前に──Sandbox、権限、ファイル境界の考え方

• URL: https://zenn.dev/aiwatch_jp/articles/agent-flow-sandbox-permissions
• 日付: 2026-06-16
• Tier: Tier 3
• 要旨: AIエージェントに作業を委ねる前に設計すべき実行境界（ファイル・コマンド・ネットワーク・認証情報の4軸）をまとめたガイド記事。最初はread-onlyから始めて段階的にwrite権限を増やす、secretは見せない設計にする、という実務的なアプローチを解説している。

詳細

sandboxを「閉じ込める箱」ではなく「作業机」として捉え直す視点が提示されている。sandbox層はworkspace境界・process境界・network境界・language runtime境界・remote sandbox境界の5層に分かれる。

境界設計の4軸はファイル（どのディレクトリを読み書きするか）・コマンド（何を実行するか）・ネットワーク（外部への出口）・認証情報（API keyやDB credentialを見せるか）。特にsecretは「見ても使わないでください」より「見えない設計」が重要で、.envをread対象から外し、本番credentialを開発環境に置かず、外部APIはmockで済ませることを推奨している。

browser agentではprompt injectionリスクがある。Webページに「前の指示を無視して…」という悪意ある指示が埋め込まれている可能性への対策も必要になる。大きいタスクでは段階的に権限を増やす（read-only調査→failing test追加→実装→review）アプローチが安定する。境界違反はCompound noteとして次回フローのAGENTS.mdとreviewチェックリストに反映することで再発を防ぐ。

Agent Teams と Dynamic Workflows は何が違うのか — 『独立セッション』と『サブエージェント』の決定的な差

• URL: https://zenn.dev/mdtechknowledge/articles/agent-teams-vs-dynamic-workflows
• 日付: 2026-06-16
• Tier: Tier 3
• 要旨: Claude Codeの「Agent Teams」と「Dynamic Workflows」は両方ともマルチエージェント機能だが構造が根本的に異なる。Dynamic WorkflowsはJavaScriptコードで制御される従属サブエージェントの大量並列実行基盤であり、Agent Teamsは双方向通信できる対等な独立セッション同士の協働チームである。

詳細

Dynamic Workflowsではagent()が生むのは親に従属するサブエージェントで、ログも通常のサブエージェントと同じ場所（~/.claude/projects/...subagents/agent-<id>.jsonl）に保存される。親→子の一方向通信でコードが決定論的に大量並列実行（同時最大16・総計最大1000）し、タスク完了後に消滅する。

Agent Teamsは実験的機能で環境変数で有効化する。チームメイトはそれぞれ独立したコンテキストウィンドウを持ち、共有タスクリスト・ダイレクトメッセージ・自動配信の3方式で双方向通信できる。リーダーが終了してもチームメイトのセッションは残り続ける点が最大の違い。

重要な共通制約として、いずれも「すでに別のセッションで走っているタスクを後から監視する」ことはできない。既存別セッションの外部監視が必要な場合はファイル経由の監視で対応する必要がある。使い分けは「使い捨ての大量並列＝Dynamic Workflows、生き続ける少数の協働＝Agent Teams」。

Claude CodeとCodex CLIのテレメトリーをGrafana Cloudで見る

• URL: https://zenn.dev/ymotongpoo/articles/20260616-ai-cli-otel-grafana
• 日付: 2026-06-16
• Tier: Tier 3
• 要旨: Claude CodeとCodex CLIのOTelテレメトリーをGrafana Alloy経由でGrafana Cloudに送り、コスト・トークン・TTFT・レイテンシーを可視化した実践報告。両CLIともdelta temporalityでメトリクスを送るためMimirに弾かれるという罠があり、Claude Codeは環境変数で、CodexはAlloyのプロセッサで変換対応している。

詳細

アーキテクチャはClaude Code+Codex→127.0.0.1:4318（OTLP）→Grafana Alloy→Grafana Cloud OTLP gateway。認証トークンをCLI設定に置かない設計のために中継Alloyを1段挟んでいる。

Claude CodeはsettingsのenvブロックでOTel環境変数を設定し、CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1でトレースも有効化。トレースはclaude_code.interaction→claude_code.llm_request→claude_code.toolのスパンツリー構造。Codexは~/.codex/config.tomlの[otel]セクションで設定するが、環境変数展開が機能しない（${VAR}が文字列のまま送信される）という実証済みのバグがある。

メトリクスのdelta→cumulative変換はClaude CodeはOTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=cumulativeで対応し、Codexは設定がないためAlloyのotelcol.processor.deltatocumulative（experimentalコンポーネント）で変換する。Grafana Cloud AI Observabilityはgen_ai.*規約前提のためclaude_code.*/codex.*は非表示となり、CLIごとの専用ダッシュボードをgcx CLIで作成して対応した。

2026年6月現在の Claude Code 開発フロー

• URL: https://zenn.dev/arm_techblog/articles/7712cde19988c8
• 日付: 2026-06-16
• Tier: Tier 3
• 要旨: Claude Codeを2025年後半から継続的に使い込んできたフロントエンドエンジニアが、2026年6月時点の開発フローを公開した。Planモードをデフォルトにした計画駆動の開発、Stop Hookによる5フェーズ自動品質ゲート、Plugin（superpowers/code-simplifier/codex）の組み合わせが軸になっている。

詳細

permissions.defaultMode: planを設定することでClaude Codeはいきなり実装せず計画ファイルを作成して承認を待つ。計画ファイルには要件チェックリストとテストケースをチェックボックス形式で記載し、この完了条件がStop Hookの品質ゲートの検証対象になる。

Stop Hook（dev-flow-gate.sh）は5フェーズを順番に通過させる。Phase1は計画ファイル形式のコンプライアンス検証、Phase2はチェックリストと実際のコード変更の同期検証（計画が形骸化しないための仕組み）、Phase3はcode-simplifier Pluginの/simplify呼び出し、Phase4はcodex Pluginの/codex:reviewによるコードレビュー、Phase5はfeatureブランチでのコミット+Draft PR作成。

PreToolUse Hookでgit commitの直接実行をブロックし、/commitスキル経由のConventional Commitsのみ許可する設計にしている。ブラウザ動作確認は/browser-checkスキルがplaywright-cli経由でlocal（状態を作り込む用）とstaging（実機確認+PR証跡）の2モードで実行する。実装の主役をClaude Codeに移す一方、人間が担う部分は計画レビューとセルフレビューに絞られている。

Claude Codeで作れるものが増えた後、人間に残る「意見」と「削る判断」

• URL: https://zenn.dev/53able/articles/3e2c4813638ef3
• 日付: 2026-06-16
• Tier: Tier 3
• 要旨: AIコーディングで作れるものが増えた後に人間が果たすべき役割を、Anthropic社員Zara Zhangの発表「Code as a Medium for Storytelling」を参照しながら考察した記事。機能差別化より意見差別化が重要になり、AIには完成仕様ではなく行動の現実と違和感を渡すことが有効だと論じる。

詳細

Zara Zhangの開発スタイルは「違和感駆動」で、完成仕様より先に「このUIでは自分はボタンを押さない」「この情報形式では読み切れない」という行動の現実から出発する。Tab OutはChrome新規タブページを入口にしたタブ管理で「ボタンを押さない」現実に合わせた設計が特徴的。

AIに渡すべきは解決策ではなく「どの画面ならすでに開いているか」「どのボタンなら押さないか」という行動の現実で、これが設計の起点になる。Frontend SlidesのAnti-AI-Slop方針（汎用的なAI風デザインを避けるcurated distinctive styles）はAIに美意識を渡すための仕組みとして機能している。

「作れる機能と使う機能は違う」という指摘は重要で、AIは機能を足すのが得意すぎるため削る判断が人間の役割になる。Tab OutのREADMEに「No server. No account. No external API calls.」とあるように、作れたはずの複雑な機能を意図的に削いだことがプロダクトの意見を強くしている。「build first, understand later」という学習順序の変化も提示されており、コーディングとエンジニアリングを役割として分ける視点が整理されている。

【Claude Code】作業中の AI に介入する steer・queue・中断の正確な使い分け

• URL: https://zenn.dev/takna/articles/claude-code-intervention-keys
• 日付: 2026-06-16
• Tier: Tier 3
• 要旨: Claude Code作業中のキー操作（steer・queue・中断・stash・rewind等）を公式ドキュメントに基づいて整理した早見表と解説記事。最も誤解されやすい点は「作業中にEnterを押してもツールは止まらない（steer）」という点で、ツールを止めたい場合はEscが正しい。

詳細

主要キー操作のまとめ:

• Enter（作業中）: 実行中のツールを止めずにメッセージを送信し、次のステップ決定前に反映させる（ソフトなsteer）
• Esc: 現在の応答・ツール呼び出しを中断するが、それまでの作業は保持する
• Ctrl+C: 実行中は中断、何も動いていなければ入力クリア、2回で終了という「終了寄り」のキー
• Esc Esc: 入力欄に文字があれば下書き削除、空ならrewindメニュー（コード+会話を過去時点に復元）
• Ctrl+S: 書きかけのプロンプトを一時退避（stash）し、別の指示を送った後に自動復帰
• Shift+Tab: パーミッションモードを循環（default→acceptEdits→plan→auto）
• Ctrl+B: 実行中のbash/エージェントをバックグラウンド化

queueについてはEnterの連続送信で積み上げられるが、最新の1件のみ↑で取り出せる。途中の1件だけを取り消すUIは現時点で存在しない。

/btwコマンドはツールアクセスなし・履歴に残らない脇道質問として機能し、本流の処理を止めずに確認できる。Ctrl+Tはタスクリスト表示の切り替え。

Claude Code の許可プロンプトを安全網を外さず減らす — 在席と無人で最適解は違う

• URL: https://zenn.dev/kojisumiyoshi/articles/claude-code-permission-prompts-guide
• 日付: 2026-06-16
• Tier: Tier 3
• 要旨: Claude Codeの許可プロンプト削減と安全網維持の両立は「在席か無人か」という1軸で最適解が分かれる。在席ではautoモード+sandboxで減らして残りを即答し、無人ではdontAskモードでプロンプト自体を出さず自動denyとエージェントの自己修正で回すのが正道。

詳細

評価順はdeny→ask→allow→modeの固定順で、どのルールにも当たらない場合にdefaultModeが作用する。askはallowより優先されるため「より具体的なallow」があってもaskが一致すればプロンプトが出る。

sandbox（macOSはSeatbelt）の書き込み可能境界はCWDとその配下。autoAllowBashIfSandboxed: trueで箱に収まるBashはプロンプトなしで実行される。秘密情報はpermissions.deny（Readツール経由）とsandbox.filesystem.denyRead（Bash経由）の二層で遮断しないと片方からの漏れが残る。

在席向けの設定はdefaultMode: auto+sandbox+named-scriptのscoped allow+危険操作のask。無人向けはdefaultMode: dontAsk+allowUnsandboxedCommands: false（Strict sandbox）+network narrowing+git外データのbackup。dontAskではdenyがエージェントに即返るためエージェントが許可される書き方に自己修正して進み続けられる点が重要。bypassPermissionsはローカル運用向けではなく隔離コンテナ専用。

Claude Code の Ultraplan 解説 — クラウドで計画、好きな場所で実行

• URL: https://zenn.dev/tatsuqumo/articles/27c3a0bd6b642c
• 日付: 2026-06-16
• Tier: Tier 3
• 要旨: Ultraplanはローカルのプランモードを補完するクラウド計画機能で、計画フェーズをクラウドに移してWebエディタでレビュー・編集した後、クラウドかローカルかを選んで実行できる。Claude.ai直接認証（Pro/Max）かつGitHubリポジトリが必要で、Amazon Bedrock/Vertex AI環境では利用不可。

詳細

/ultraplanを実行するとクラウドセッションがリポジトリを分析して計画ドラフトを生成し、WebエディタでインラインコメントやリアクションによるレビューがUIで行える。計画に納得したら「クラウドで実行してPR作成」「ターミナルにテレポートしてローカル実行」「キャンセルしてファイル保存」の3択を選ぶ。

ローカルプランモードとの違いは「ターミナルの占有あり・テキストベースのやり取り」対「ターミナル解放・Web UIでのレビュー・計算リソースはクラウド」。ローカルが小〜中規模向けとすれば、Ultraplanは大規模リファクタやチームレビューが必要な場面向け。

ultraファミリーの全体像として「ultraplan（設計）→ultracode（最大1000エージェント並列実装）→ultrareview（マージ前レビュー）」というサイクルが想定されている。v2.1.91以降が必要で、v2.1.101以降はクラウド環境の自動作成に対応。Zero Data Retention有効な組織では利用不可。

GLM-5.2は本当にオープンソースになったのか？月18ドルからClaude Codeに挿して試す

• URL: https://zenn.dev/ino_h/articles/2026-06-16-glm-5-2-opensource-cost
• 日付: 2026-06-16
• Tier: Tier 3
• 要旨: Zhipu AIが2026年6月13日に発表したGLM-5.2（744B MoE、1Mトークンコンテキスト）のオープンソース化について、一次ソースを直接確認したところ2026年6月16日時点でモデル重みはHuggingFaceにもGitHubにも存在しない。公開予定は翌週。現時点での唯一の試用経路はGLM Coding Plan（月18ドル〜）のAnthropic互換エンドポイント経由。

詳細

検証方法はgh api repos/zai-org/GLM-5/tags（空）、gh api repos/zai-org/GLM-5/releases（空）、組織全体のリポジトリ検索（GLM-5.2のリポジトリなし）、ブログ/docs URLへのアクセス（404）の4点で、いずれも重み未公開を確認。発表と公開のタイムラグが存在する。

GLM Coding PlanはAnthropicの互換エンドポイント（https://api.z.ai/api/anthropic）を提供しており、ANTHROPIC_AUTH_TOKENとANTHROPIC_BASE_URLを設定するだけでClaude Codeのモデルスロットを置き換えられる。全プラン（Lite/Pro/Max）でGLM-5.2を追加料金なしで利用可能。料金の公式表記は「月18ドルから」のみで、プラン別の月額内訳は非公表。

従量課金（単体API）のGLM-5.2価格は未公表。前世代のGLM-5.1が入力$1.40/出力$4.40/1Mトークン（参考値）。744B MoEのセルフホストはコンシューマーGPU向けではなく、「オープンソース≠無料で気軽に動かせる」という点を強調している。

もうプロンプトは書かない、ループを書く — Claude Code作者とOpenClaw作者が辿り着いた /goal と /loop

• URL: https://zenn.dev/kenimo49/articles/write-loops-not-prompts-goal-loop
• 日付: 2026-06-16
• Tier: Tier 3
• 要旨: Claude Code作者のBoris ChernyとOpenClaw作者のPeter Steinbergerが独立して同じ結論「プロンプトではなくループを書く」に到達したことを軸に、/loopと/goalの仕組みと本質を解説した記事。/goalの真の革新は完了判定を作業者とは別の新鮮なモデルに委ねる設計にある。

詳細

/loopは時間間隔で回るループで、間隔を省略するとClaude自身がタスクの性質に応じてペースを決める（self-pace）。監視・定期メンテナンスに向く。/goalは完了条件が満たされるまでループが自動的に続く。毎ターン終了後に作業役とは別の小型モデル（デフォルトHaiku）が「条件達成か否か」を判定し、未達成なら理由を添えて次のターンへ進む。

「やったつもりで止まる」AIエージェントの持病を、判定役を別モデルに分離することで構造的に解消した点が本質的な革新。OpenClawも同様に「提案エージェントと評価エージェントを分ける敵対的設計」を採用しており、同じ発想に収束している。

良い完了条件の3要素は「測れる終了状態（テスト結果・exit code等）」「証明の仕方（Claudeの出力で示せること）」「守るべき制約（他ファイルを変更しない等）」。/goalはclaude -p "/goal ..."の形で非対話実行（cronなど）でも使えるため、ループ駆動の自動化と直接接続できる。