どうも、マイクです。おはようございます。
二千二十六年九月七日、月曜日の朝七時を回りました。
ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ゆるっと楽しく紹介していきます。

さて、きょうはですね、全部で五本の記事をご紹介していきます。
どれも「AIとの付き合い方」とか「ウェブのアクセシビリティ」とか、「金融の戦略」とか、けっこう頭を使うテーマが多いんですが、できるだけ噛み砕いてお話ししますので、コーヒー片手にのんびり聞いてください。

まず一本目。
八ビットドーマイクロ、っていう、すごく小さいゲームコントローラーをご存じの方もいると思うんですが、その「八ビットドーマイクロ」をターミナル用のコントローラーに割り当てて、片手操作と音声入力を組み合わせることで、身体への負担を減らしつつ、ダラっと作業できる環境を作っている、というお話です。

この方は、Claude Code側の設定、`settings.json`ですね、ここでパーミッションをオート、`auto`にしたり、`viewMode`をフォーカス、`focus`にしたり、`advisorModel`を`fable`にしておくことで、「エージェントに自律的に実装と判断を進めてもらう」という前提で環境を組んでいます。
つまり、人間がいちいち指示を細かく出さなくても、AI側にだいぶおまかせできるようにしているわけですね。

Macのスリープも「作業中だけ無効」にしておいて、さらにおもしろいのが、SidePulseというツールで、SDカードスロットのLEDライトを通知デバイスとして使っているんです。
進行中なのか、完了したのか、要対応なのかを色で表して、「画面を見ていなくても、今AIがどういう状態なのか分かる」運用にしている。
これ、首や目がつかれないようにしたい人には、すごくありがたい工夫ですよね。

`settings.json`の差分は、`jq`で整形して、項目の順番による差分は消してしまう。
で、ステータスラインにはバッテリーの絵文字を出して、コンテキスト使用割合、どれくらいコンテキストを消費しているかを常に表示しておくなど、普段の開発フローの中に、自然に「AIの状態」を組み込んでいます。

実装と動作確認は、agent-browserやterminal-useのツールで行って、長く動かす必要があるプロセスは`zmx`経由で立ち上げておく。
必要になったら後からアタッチして中身を見る、っていうスタイルで、「人間がボトルネックにならない検証フロー」を作っているのもポイントです。

書き込みは`cage`、読み込みやコマンド実行は`guard-and-guide`で、ゆるく制限してあげる。
そしてシステムプロンプトには「サンドボックスでできないことは諦めろ」とはっきり書いておく。
これによって、「AIの自律性はあまり落とさずに、危険な操作だけを防ぐ」という、絶妙なバランスを取っています。

セッションログは別のツールで見られるようにしておいて、`ponytail`みたいなローカル専用ツール由来のコメントは、そのままチームに流すと分かりにくいので、`CLAUDE.md`側のルールで「誰が見ても意味が分かる表現に書き換えること」と指示する。
こうやって、ローカルの便利ツールとチーム開発がケンカしないようにしているのもおもしろいところです。

さらに、AI用の`z-ai/`ディレクトリを用意して、ここはgit管理の外側に置いておく。
計画書とか、そのときどきのメモはそこに保存する一方で、長期的な知識はClaudeのメモリー機能に任せていく、という方針にシフトしています。

この環境の中では、`/address`とか`/reply-review`といったコマンドや、GitHub ActionsのLintルール、それから`rebaser`や`reworder`みたいなエージェントを活用して、定型作業はどんどんAIに寄せていきます。
ビルトインのレビュー機能と`ponytail`を組み合わせることで、「余計な実装をさせない」体制を整えている、というのも印象的です。

そして、この方は半年から四半期に一度くらいのペースで、設定の棚卸しをして、いらなくなったルールとか、古くなった前提を整理しているんですね。
「実装はAIに任せて、人間はワークフローの設計と見直しに集中する」というスタイルで、環境をアップデートし続けている。
いやあ、「楽をするために徹底的に考える」って、まさにこういうことだなあと思いました。.

.。.

続いて、二本目。
ウェブページによくある「トップへ戻るボタン」についての、アクセシビリティの観点からの考察です。

ページの右下とかに、画面に追従する形で固定表示されているトップへ戻るボタン、見たことあると思います。
この記事では、あのタイプのボタンが、特に視覚や操作にハンディのある人を中心に、多くの人にとって負担になりやすい、という話をしています。

具体的には、ボタンがアイコンだけで表示されていて、スクリーンリーダーなどの読み上げソフトに、役割や目的がうまく伝わらないことがある。
さらに、押したあとにニュルっと長いスクロールアニメーションが流れると、それで気分が悪くなってしまう人もいる。
ほかにも、ボタンがコンテンツの上に重なってしまって、テキストや、キーボードフォーカスが今どこにあるのかを隠してしまうことがあるんですね。

こういった問題は、国際的なアクセシビリティ基準であるWCAG、ウェブ・コンテンツ・アクセシビリティ・ガイドラインの複数の項目に抵触しやすい、と説明されています。
「予期しない動きをしないこと」「コンテンツを隠さないこと」「キーボードでもしっかり操作できること」など、いろんな要求に関わってくるんですね。

もちろん、解決のための実装テクニックとか、配置の工夫というのはあります。
ただ、そもそもとして、OSやブラウザ側に「一番上へ戻る」ショートカットが用意されているので、「本当にボタン自体が必要なのか？」というところから、立ち止まって考えるべきじゃないか、という指摘がされています。

同じ問題は、追従するバナーとか、チャットを開くためのボタン、いわゆる固定コンポーネント全般に共通している、とも書かれています。
「クリックで閉じられるようにしておけばいいでしょ」という単純な話ではなくて、そもそもその位置に常に出しておくことが、どんな人に、どんな負担をかけているのか。
そこまで含めてデザインしないといけないんですね。

一方で、スクロール操作そのものが身体的に負担になる方にとっては、「一発で上へ戻れるボタン」が助けになるケースも、もちろんあります。
なので結論としては、「トップへ戻るボタンはけしからん、全部やめろ」ではなくて、「本当に必要かをデザインの段階から問い直そう。設置するなら、WCAGなどの基準をちゃんと満たすように、慎重に設計しよう」という、バランスの取れたメッセージで締めくくられています。.

.。.

では三本目。
これは、ちょっと金融・クオンツ寄りの話題で、「単一の特徴量でロング・ショート戦略を組むときの注意点」についてのお話です。
ここでは、夜間と日中のリターンの差、という特徴量を例にしています。

たとえば、「夜間に強い銘柄をロング（日中持ち続ける）して、日中に強い銘柄をショートする」といった戦略を考えたときに、「じゃあ、夜間と日中のリターン差が、できるだけ大きく違う銘柄同士をぶつければいいんでしょ」と、単純に考えてしまいがちなんですね。

でも、それをそのままやると、「外需系の銘柄をロングして、内需系の銘柄をショートする」といった形になりやすい。
そうすると、為替の動きとか、業種セクター全体の動きなど、自分が本当は取りたかったリスクとは別の、「意図していない共通リスク」を大量に抱えてしまう可能性があります。

そこで記事では、過去数年分の週次リターンなどを使って、まず「相関が高い銘柄ペア」を選ぶ、というプロセスを提案しています。
その上で、金額の比率を調整して、市場全体、セクター、為替などに対する感応度を、できるだけ打ち消すように組む。
そうすると、残った損益が、「夜型なのか日中型なのか」といった、もともとの特徴量に由来する部分に、より近づいていく、という考え方です。

ただしここで難しいのが、「相関が高い銘柄ほど、値動きのドライバーも似ている」ので、夜間と日中のリターン差、つまりプレミアムの違いが小さくなりやすい。
逆に、「プレミアム差を最大化しよう」とすると、ぜんぜん別のセクターの銘柄同士を組み合わせることになって、相関が下がってしまう。

なので、同じ業種なんだけど「海外売上比率だけ少し違う」とか、そういった「相関とプレミアム差のバランスが取れたペア」を探すことが重要だ、と述べられています。
そのうえで、過去データを使って、「どのくらいの相関の高さと、どのくらいのプレミアム差まで許容するか」をチューニングしていく。
「シンプルな因子戦略でも、裏側にはこういうバランス取りの工夫があるんだなあ」と学べる内容になっています。.

.。.

四本目。
ここからはふたたびClaude Code関連のお話で、「Rulesが期待通りに発火しない理由はどこにあるのか？」という、トラブルシューティング寄りの記事です。

ポイントは、「`paths`付きのRulesは、Readツールでファイルを読んだときだけ読み込まれる設計になっている」というところ。
ところが、自動モード、auto mode側のシステムプロンプトが、「ファイルの読み取り・検索・編集は、Bashの`cat`とか`grep`とか`sed`でやりなさい」と強く指示するように変わってきている。
その結果、モデルがReadツールをほとんど使わなくなってしまっている、という構造があるんです。

そうするとどうなるかというと、`paths`で絞り込んでいたRulesや、Read/Edit/Writeに連動して動くHooksが、まるっとスキップされてしまう。
でも、スキップされたからといってエラーにはならないので、「最近なんかルールが効かないなあ」という形でしか表に出てこない。
これが、いま起きている「Rulesが発火しない問題」の正体だ、というわけです。

対処法は大きく二つ紹介されています。
ひとつ目は、`CLAUDE.md`などに「ファイル操作にはReadツールを優先して使ってください」と、プロンプト上で書いておく方法。
これはあくまで「やさしくお願いする」レベルの指示ではあるんですが、Readの呼び出しが戻ってきさえすれば、Rulesも再び発火するようになるので、まず試しやすい対応策です。

もうひとつは、隠しフィーチャーフラグである`CLAUDE_CODE_THRIFTY_SONIC`という環境変数を偽にして、Bash優先のプロンプト自体を無効化してしまう方法。
こちらは、効きは強烈で、「Bashを優先しろ」という前提そのものをオフにできるんですが、将来的にこのフラグの意味や挙動が変わるリスクがあるので、その点には注意が必要だと書かれています。

さらに記事では、「権限ルールとしてのRead/Edit」と、「HooksやRulesが見ているRead/Edit」の違いについても整理されています。
権限ルールのほうは、Bash経由の`cat`や`sed`の操作も監視している一方で、HooksやRulesのマッチャーは「どのツール名が呼ばれたか」（ReadなのかEditなのかBashなのか）しか見ていない。
そのため、Bash経由で行われた編集は追えない、という構造になっているんですね。

全体を通して、「エージェントのハーネス機能は、モデルがどのツールを選ぶかに強く依存している」というメッセージが語られています。
そして、その前提が静かに崩れてもエラーにはならないので、ログを残したり、定点観測をしたりして、「サイレントな挙動変化をちゃんと検知すること」が本当に大事だよ、と締めくくられていました。.

.。.

ラスト、五本目。
こちらもClaude Codeの設定と工夫を紹介する、Tips系の記事です。
けっこうガチガチにセキュリティと安全性を高めた構成のお話になっています。

まず大きな工夫として、`managed-settings.json`という設定ファイルを、ルート権限で管理しています。
つまり、ふだんの自分のユーザー権限では、うっかり書き換えられないようにしておく。
これによって、多層防御と、「自分でも気軽には変えられない仕組み」を作っているんですね。

この`managed-settings.json`の中では、サンドボックスの利用を必須にしたり、`.ssh`や`.env`といった機密性の高いファイルの読み書きを禁止したりしています。
さらに、`git push`とか`npm install`といった、プロジェクトの状態を大きく変えてしまいがちなコマンドを、`permissions.deny`でブロックしている。
AIに任せても安全な範囲と、絶対に触らせたくない範囲を、線引きしているわけです。

`allowManagedReadPathsOnly`や`strictAllowlist`といった設定も使っていて、サンドボックスの中からBashでファイルを読んだり、外部ネットワークに出たりするのを原則禁止にしています。
そのうえで、「通信が必要なプロジェクト」だけ、各プロジェクトの`.claude/settings.local.json`のほうで、個別に許可ドメインを足していく運用。
デフォルトは閉じておいて、必要な案件だけピンポイントで開ける、というポリシーですね。

ホームディレクトリ側の`~/.claude/settings.json`にも、同じようなdenyルールをあらためて書いておきますが、こちらにはモデルの指定や通知設定など、日常的に変える可能性がある項目だけを足していく。
`CLAUDE.md`のほうには、「削除系のコマンドは禁止」とか、「新しいライブラリを導入する前には、脆弱性をチェックすること」といった行動指針を書いておき、厳密な制限というよりは、AIの振る舞いを良い方向に誘導するために使っている、というのもポイントです。

さらに、Claude自身に設定ファイルを直接いじらせないように、`.claude`以下のディレクトリは、EditツールでもBashでも触れないようにしてあります。
また、`excludedCommands`という機能は、見た目上は特定のコマンドを除外できて便利なんですが、複合コマンド経由で情報が漏れてしまうリスクがあるので、安易には使わないようにしている、という注意も書かれていました。

`.env`などの秘匿情報については、サンドボックス側の`denyRead`と`denyWrite`、それからpermissions側の`Read(…) deny`、両方に設定を入れて、Bash経由でもReadツール経由でも、確実にアクセスを止められるようにする。
設定を入れたあとには、ダミーファイルを用意して、「ちゃんと拒否されるか」「許可したものは読めるのか」をテストケースとして確認しているそうです。

全体として、「AIにたくさん任せたいけど、その前に設定と防御線をちゃんと固めておく」という、すごく実務的なノウハウが詰まった記事でした。

……というわけで、きょうは全部で五本、
八ビットドーマイクロを使った、身体に優しいAI開発環境の話。
トップへ戻るボタンとアクセシビリティの話。
単一特徴量でロング・ショート戦略を組むときの、相関とプレミアム差のバランスの話。
Claude CodeのRulesがなぜ発火しなくなるのか、その構造と対処の話。
そして最後に、Claude Codeの設定を多層防御でガチっと固めるTips集。
この五つをご紹介しました。

気になる記事があった方は、ぜひショーノートから、元の記事もチェックしてみてください。
きょうはだいぶ技術寄り・金融寄りの内容でしたが、「AIに任せるところ」と「人間が設計するところ」の境界線って、どのテーマにも共通してましたね。

番組「zenncast」では、みなさんからの感想や、「こんなテーマを取り上げてほしい」というリクエストもお待ちしています。
ラジオネームを添えて、気軽に送ってください。

それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。また次回のzenncastでお会いしましょう。