「この画面はなんとなく使いにくい」「入力箇所に迷う」といったユーザーの不満を探ると「人間の認知の仕組み」を無視している場合があります。 本記事では、人間の視覚的な認知法則を体系化した「ゲシュタルト心理学」をベースに、ユーザーが直感的に操作できる、画面設計のロジックを、入力フォームを例に解説します。 ユーザーが直感的に利用できる画面デザインには「論理」があります。 フロントエンドエンジニアやプロダクトマネージャーの方にもぜひ知っていただきたい内容です。 ゲシュタルト心理学とは？ 「ゲシュタルト（Gestalt）」はドイツ語で「形」「姿」「形態」を表す言葉です。 ゲシュタルト心理学は、20世紀初頭にドイツで生まれた心理学で、簡単に言うと、「人間は物事をバラバラのパーツとしてではなく、まとまった一つの全体（ゲシュタルト）として認識する」という法則を説いたものです。 これは「プレグナンツの法則」とも呼ばれ、私たちの脳が複雑な情報を可能な限りシンプルで秩序ある形として理解しようとする働きを指します。 人間の脳は、無意識のうちに視覚情報を整理し、グループ化しようとします。この脳の特性（錯覚）をUIデザインに逆算して組み込むことで、「説明書を読まなくても使い方や関係性がわかる画面」を作ることができます。 今回は、フォーム設計に直結する3つの法則を紹介します。 1. 「近接の法則」で関係性を明確にする 近接の法則とは、「物理的に距離が近いもの同士は、同じグループとして認識される」という法則です。基本でありながら抜けやすいのがこの「余白（マージン）」の扱いです。 わかりにくいUI 「名前」というラベル、その入力欄、次の「メールアドレス」というラベルが、すべて同じ8pxの等間隔で並んでいる。 人間の脳は、どれとどれがペアなのかを一瞬で判断できず、視線が迷います。 わかりやすいUI ラベル（項目名）と入力フィールドの関係性を視覚的に明示するために、余白にメリハリをつけます。 ラベルと入力欄の余白： 4px〜8px（近づける） 次の項目との余白： 24px〜32px（離す） このように「ペアとなる要素の距離」を「他の要素との距離」よりも明らかに短くすることで、ユーザーは無意識に「このラベルはこの入力欄に対するものだ」と認識でき、入力スピードが向上します。 2. 「類同の法則」で操作の期待値を揃える 類同の法則とは、「形、色、大きさなどの視覚的特徴が似ているものは、同じ機能や性質を持つと認識される」という法則です。 わかりにくいUI テキスト入力欄（input）と、ドロップダウン（select）の枠線のデザインや背景色が違う。 わかりやすいUI ユーザーの「これは入力できる場所だ」というメンタルモデルを裏切らないよう、要素のスタイルを統一します。 入力可能なフィールドは、角丸（border-radius）や枠線の色、フォーカス時のハイライト色（outline）をシステム全体で統一します。 同様の機能を持つものは同じ見た目にし、違う機能を持つものは明確に見た目を変えることで、ユーザーは画面内のルールを瞬時に学習できます。 3. 「閉合の法則 / 共通領域の法則」で複雑さを軽減する 閉合の法則や共通領域の法則は、「線で囲まれたり、同じ背景色の上に配置されたりした要素は、ひとつのグループとして認識される」という法則です。 入力項目が数十個に及ぶ巨大なフォームで非常に有効です。 わかりにくいUI 「会社情報」「担当者情報」「請求先情報」などの異なるカテゴリの入力項目が、仕切りもなく延々と縦に羅列されている。 ユーザーは情報のゴールが見えず、心理的ハードルが高まり離脱に繋がります。 わかりやすいUI 情報を意味のあるグループに分け、視覚的な境界線を設けます。 カードUIの活用: 「会社情報」で1つの白いカード、「請求先情報」で別のカードにし、背景（グレー系）の上に配置します。 セクション区切り: カードを使わない場合でも、セクション間に罫線（ボーダー）を引き、見出し（h2やh3）を大きく配置することで情報のまとまりを作ります。 「ここからここまでがセットだな」と視覚的に区切られているだけで、ユーザーが処理しなければならない情報の認知負荷は下がります。 おわりに：デザインは「エンジニアリング」できる 「デザインが垢抜けない」「使いにくい」との評価を受けて、つい「色」や「装飾」といった表面的な要素に目が行きがちですが、UIにおける使いやすさは、今回ご紹介したような「余白」と「配置」の論理的な設計で、ほとんど決まります。 次に入力フォームを実装する際に、「この余白はどう認識されるか？」という視点を持ってみてください。それだけで、プロダクトのUXは向上するはずです。 余談 ちなみに、上記の「複数の要素をまとまりとして捉える」のがゲシュタルト心理学の基本ですが、それとは反対に、特定の対象を凝視し続けることで「まとまり」が見えなくなり、バラバラな部分としてしか認識できなくなる現象があります。これが「ゲシュタルト崩壊」です。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ゲシュタルト心理学で紐解く、ユーザーが「迷わない」画面設計 first appeared on SIOS Tech Lab .

こんにちは、OSSよろず相談室のSKです。 OSS に関するお問い合わせが日々寄せられる中で、今回は統合監視ツール「Zabbix」に関連して寄せられた、セキュアな通信に関するお問い合わせを2つご紹介します。 どちらもZabbixのWebコンソール（GUIポータル）へのSSL/TLS通信を安全に保つための内容ですが、Zabbix本体ではなく、Webサーバ側（Apache httpd）の ssl.conf の設定を変更します。 ケース1：TLS1.2のみに通信を制限したい 【お問い合わせ内容】 ZabbixのWebコンソールにブラウザで通信する際、現在TLS1.0と1.1が使用できる状態です。これをTLS1.2のみに制限する方法はありますか？ 【サポートからの回答】 こちらはZabbix自体の設定ではなく、Web画面を提供しているApache httpdの mod_ssl の設定となります。 /etc/httpd/conf.d/ssl.conf にて、以下のように SSLProtocol ディレクティブを設定することで、TLSv1.0 と TLSv1.1 の使用を無効化できます。 【修正例】 SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 上記のように記述することで、「すべてのプロトコル（All）を許可した上で、安全性の低いプロトコルを明示的に除外（マイナス記号 – を付与）」することになり、結果として TLSv1.2 以降のみが利用可能になります。 設定変更後は、必ずApacheの再起動またはリロードを行って設定を反映させてください。 ケース2：セキュリティ診断で指摘された古い暗号化方式を無効化したい 【お問い合わせ内容】 Zabbix環境に対してセキュリティ診断を実施したところ、Zabbixフロントエンド（Web管理画面）との暗号化通信において、古い暗号化方式の利用（SWEET32やBar Mitzvahなどに該当する事象）が検出されました。 暗号化通信は継続しつつ、検出された暗号化方式だけを利用しないように設定変更するにはどうすればよいでしょうか。 【サポートからの回答】 こちらもケース1と同様に、Apacheの ssl.conf の設定変更で対応可能です。それぞれの事象に関する原因と対処法をご案内します。 1. 3DESを使用する暗号化方式（SWEET32関連）への対応 参考情報： Red Hat 社の情報 / CVE-2016-2183 https://access.redhat.com/security/cve/cve-2016-2183 ちょっと気になる雑学：なぜ「SWEET32（誕生日攻撃）」？ 「ある部屋に23人いるだけで、誕生日が同じペアが50%以上の確率で存在する（誕生日のパラドックス）」という数学の法則を応用した攻撃手法です。「特定の鍵」を狙うのではなく「どれでもいいから暗号データの重複」を狙うため、直感より遥かに少ないデータ量で解読されてしまいます。3DES暗号の場合、通信量が「32GB」に達したあたりでこの重複確率が跳ね上がることから、この名前がつきました。 3DESを許可する記述や、3DESを使用する暗号化アルゴリズムが明示的に指定されていると、Sweet32 攻撃の影響を受けます。これらを削除することで対処が可能です。 修正例1（3DESが明記されている場合）: 変更前 apache SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA 変更後（”3DES”の記述を削除） apache SSLCipherSuite HIGH:!aNULL:!MD5:!SEED:!IDEA 修正例2（3DESの特定のアルゴリズム名が個別指定されている場合）: 　　以下の場合は” EDH-RSA-DES-CBC3-SHA “が指定されています。 変更前 apache SSLCipherSuite "ECDHE-ECDSA-AES128-GCM-SHA256 ・・・ EDH-RSA-DES-CBC3-SHA" 変更後（対象の暗号化方式 “EDH-RSA-DES-CBC3-SHA” を削除） apache SSLCipherSuite "ECDHE-ECDSA-AES128-GCM-SHA256 ・・・ " 2. RC4を含む暗号化方式（Bar Mitzvah関連）への対応 参考情報： Red Hat 社の情報 / CVE-2015-2808 https://access.redhat.com/security/cve/cve-2015-2808 Bar Mitzvahという脆弱性は、RC4 暗号アルゴリズム自体の弱点を突いた攻撃です。 ちょっと気になる雑学：なぜ「Bar Mitzvah」？ 「Bar Mitzvah（バー・ミツバ）」とは、ユダヤ教における「13歳」の男子の成人式のことです。この攻撃のベースとなったRC4暗号の弱点自体は2001年に既に発表されていたものでしたが、それから13年経った2015年になって、実用的な攻撃手法として実証（＝成人）されてしまったため、このような皮肉を込めた名前がつけられたそうです。 SSLCipherSuiteの設定に “MEDIUM” が入っていると影響を受けます。 “MEDIUM” は 128ビットの暗号化を使用するすべての暗号であるため、脆弱性診断で指摘されている暗号化アルゴリズムが許可されます。 変更前 SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 変更後（”MEDIUM” を削除） SSLCipherSuite HIGH:!aNULL:!MD5 修正の反映と、コマンドによる事後確認 設定ファイルを修正した後は、設定を適用するためにApacheのリロード（systemctl reload httpd）または再起動（systemctl restart httpd）を行います。 また、設定が正しく反映され、意図しない暗号化方式が排除されたかどうかは、 openssl ciphers コマンドでテストすることができます。 引数に修正後の ssl.conf の SSLCipherSuite の値を指定して実行し、出力結果の「Enc」列に 3DES や RC4 が無いことを確認すると確実です。 実行例 openssl ciphers -v 'HIGH:!aNULL:!MD5:!SEED:!IDEA' まとめ ZabbixのWeb画面に関するセキュリティ要件（プロトコル制限や暗号化方式の変更など）は、Zabbixの設定ファイルを探しても見つかりません。 フロントエンドで動作しているWebサーバ（今回はApache の /etc/httpd/conf.d/ssl.conf）で設定を行うのが基本となります。 セキュリティ診断などでアラートが出た場合も、慌てずにWebサーバの暗号化スイート設定（SSLCipherSuite）を見直しましょう。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OSSサポートの現場から！Zabbix Webコンソールのセキュリティ設定 first appeared on SIOS Tech Lab .

  可用性を追求する仲間が集う本音コミュニティが始動！ 今回の主役は、皆さまの現場の「HA構成」です。 泥沼だった苦労話 本当に最適？　モヤモヤする構成 クラウド全盛の今だからこその構成 あなたの「リアル」を肴に、プロ同士でガチ議論しませんか？ 企業名は伏せるので愚痴・お悩み大歓迎！詳細・申込はこちら https://ha-lounge.connpass.com/event/395533/ The post 7/9(木) 第1回 HA Lounge 開催決定！ first appeared on SIOS Tech Lab .

こんにちは。サイオステクノロジー武井です。 PlaywrightによるE2Eテストをできる限り自動化するためのエージェントとスキルを作りました。前提となるE2Eテストの説明から、実際に作ったエージェントの構成までを順に紹介します。 E2Eテストとはそもそも何か E2Eテストは、画面操作を伴うテストを自動で行うもの、つまりブラウザ操作を自動化する仕組みです。代表的なOSSが   Playwright   で、Microsoftが開発しています。以前は   Selenium   が広く使われていましたが、現在は Playwright が主流になっています。 テストの自動化という点では、ユニットテストにも自動化の手段があり、PythonならPytest、JavaならJUnitが使われます。今回扱うのはそれとは別で、ブラウザ画面の操作を伴うテストを自動化するものです。 Playwright は現在、事実上E2Eテストのデファクトスタンダードと言える位置にあります。 E2Eがカバーする範囲 先ほどテストの自動化のツールにはさまざなまなものがあると説明しましたが、E2Eテストがカバーする範囲を明確にしてみます。 E2Eテストがカバーする範囲は上図の通り、要件定義の機能要件と、基本設計の画面とコンポーネントの接続部分です。逆に、非機能要件や、画面が絡まないコンポーネント同士の結合テストはE2Eテストの対象外になります。これは当然と言えば当然で、E2Eテストはあくまで画面操作を伴うテストの自動化であり、画面が絡まない部分はそもそもE2Eの対象外だからです。 本記事の対象外とはなりますが、ユニットテストやAPIテストなど、画面操作を伴わないテストの自動化には、PytestやJUnitなどが使われます。これらはE2Eテストとは別の領域であり、今回のエージェントでは扱いません。これらは基本設計内にある画面が絡まないコンポーネント同士の結合テストや、詳細設計に定義されているコンポーネントの単体テストで使われることが多いです。 今回作ったもの ─ 3つのエージェント 今回作ったエージェントは上図のような構成で、以下のGitリポジトリから取得できます。 https://github.com/noriyukitakei/e2e-automation-agents エージェントは、次の3つに分かれています。 testspec-writer （テスト仕様書を起こす） testspec-to-code （仕様書からPlaywrightコードを生成する） test-runner （実行して結果を切り分ける） この3つは責務を完全に分離しています。 まずは testspec-writer エージェントです。これは設計書を読んでテスト仕様書を起こします。 次に   testspec-to-code   エージェントは、 testspec-writer   が作成したテスト仕様書をもとに、Playwrightのテストコードを生成します。 最後に、 test-runner   エージェントです。これは生成されたテストコードを実行し、結果を切り分ける役割を持ちます。 キモとしては、この3つのエージェントがフィードバックループを形成している点にあります。コードを生成して実行し、失敗したら原因を切り分けて、コード側の問題ならコード生成に差し戻す、という流れです。 先の図に基づいてテストを実行するまでのプロセスを説明します。 ① テスト仕様書を出力 testspec-writer エージェントが設計書を読み込み、テスト仕様書を起こします。出力先は docs/testspec/{機能名}.md というファイルです。 テスト仕様書は、testspec-formatスキルに基づき、以下の書式で出力されます。 列 内容 ケースID TC-001 等。テストコードとの対応キー 分類 正常系 / 異常系 / 境界値 テスト内容 何を確かめるか（人間可読） 事前条件 テスト開始前の状態 操作手順 ①②③ の番号付きの人間の動作 期待結果 何が画面に起きるべきか（具体的に） 要件ID 由来する設計要件（追跡用） サンプルは以下のとおりとなります。 ケースID 分類 テスト内容 事前条件 操作手順 期待結果 要件ID TC-001 正常系 正しい情報でログイン 未ログイン ①ログイン画面を開く ②メールとパスワードを入力 ③ログインを押す ダッシュボードに遷移し、ユーザー名が表示される REQ-12 ② テスト仕様書の読み込み testspec-to-code エージェントが、①で出力されたテスト仕様書を読み込みます。 ③ MCPに接続 続いて testspec-to-code エージェントが Playwright MCP サーバーに接続します。Playwright MCP は、指定したWeb画面にアクセスして画面のさまざまな情報を取得できるツールです。 ④ DOMの読み込み Playwright MCP がテスト対象のWeb画面にアクセスし、そのDOM情報を読み込みます。これにより実際のセレクター（role / label / testid）を取得でき、テストコードを生成する際に実画面とのズレが起きないようにします。 ⑤ テストコードの生成・修正 testspec-to-code エージェントが、Playwright MCP から取得したセレクター情報とテスト仕様書の内容をもとに、テストコードを生成します。出力先は tests/e2e/{機能名}.spec.ts です。 ⑥ テストコードの読み込み test-runner エージェントが、⑤で生成されたテストコードを読み込みます。 ⑦ テスト実行 test-runner エージェントが、読み込んだテストコードをもとにテスト対象のWeb画面に対してテストを実行します。 テストが成功すればそのままで問題ありませんが、失敗した場合は原因を次の4つに分類します。 A：セレクターのズレ 。たとえばコードが   getByTestId   を使っている場合、既定では   data-testid   を探しに行きますが、実際のDOMには   data-test   と書かれている、というケースです。画面自体は正常なのに要素が見つからず、タイムアウトしてしまいます。 B：タイミング待ち不足 。テストの待ち方の問題です。ログイン直後など、まだ描画が完了していない段階でアサーションを評価してしまい、タイムアウトする場合がこれにあたります。 C：実装側のバグ 。アプリ本体、つまり仕様と挙動の不一致です。仕様書には合計   $43.18   と書かれているのに、実画面では   $40.00   が表示されている、といったケースで、これは単なるバグです。 D：環境・データ起因 。サイト障害で接続できない、といった環境側の問題です。 分類に応じて、その後の処理が変わります。AとBはコード側の問題なので、 testspec-to-code   へ差し戻します。たとえばAはセレクターの指定ミスなので、生成役にその箇所を修正させます。 一方でCとDは、コードを直しても解決しません。アプリ自体の不具合や環境起因の問題であり、 testspec-to-code   では対応のしようがないため、人間に通知して停止します。 分類 何が原因か 差し戻し先 A セレクターのズレ（コード側） testspec-to-code B タイミング待ち不足（コード側） testspec-to-code C 実装側のバグ（仕様と挙動の不一致） 人間 D 環境・データ起因 人間 この testspec-to-code と test-runner のフィードバックループの上限回数は3回に設定しています。3回コードを修正してもテストが通らない場合は、コード側の問題ではない可能性が高いので、人間に通知して停止します。 ⑧ 差し戻し 実行結果の失敗原因がA（セレクタずれ）またはB（タイミング待ち不足）だった場合は、testspec-to-code エージェントに差し戻され、Playwright コードを修正します。以降は②〜⑦と同じ流れを繰り返します。この差し戻しループは最大3回までで、3周しても失敗が続く場合（C：実装バグ疑い／D：環境・データ起因）は人間にエスカレーションします。 やってみよう とは言いつつも、実際にやる手順は Claude Code を起動して「docs/design にある設計書をもとに、E2Eテストを実行して」と指示するだけです。あとはエージェントが自動で動いてくれます。必要なモジュールがなければ、それも自動でインストールしてくれます。 E2Eテストでよく使われる Sauce Demo（ https://www.saucedemo.com/ ）を例に、実際にやってみましょう。 先ほど紹介したソースコードのディレクトリには、この Sauce Demo を題材にした設計書がすでに入っています。パスは docs/design/saucedemo.md です。これをもとに E2Eテストを実行してみます。 以下を Claude Code のプロンプトにコピペしてみてください。 saucedemoのE2Eテストを実行して。仕様書はdocs/design/saucedemo.mdにあるよ。 すると、必要なモジュールなどがなければ自動でインストールされます。 あとはエージェントにお任せです。テストコードの生成から実行、失敗した場合の原因の切り分けと差し戻しまで、すべて自動でやってくれます。 テストコードは tests/e2e/saucedemo.spec.ts に保存されます。 エビデンスは tests/evidence フォルダに保存されます。Playwright がテスト実行時にスクリーンショットを撮って残してくれます。 レポートは2種類出力されます。ひとつは HTML レポートで、tests/playwright-report/ に保存されます（npx playwright show-report tests/playwright-report で開けます）。もうひとつは CI やテスト管理ツールへの取り込み用の JUnit XML で、tests/test-results/junit.xml に保存されます。 実行結果は以下のようになりました テストコードの生成と実行、つまりtestspec-to-code と test-runnerのフィードバックループが3周しているのがわかりますでしょうか？ 例えば、1周目は、セレクターのズレです。テストコードが  getByTestId  を使っているのに、実際のDOMには  data-test  と書かれていました。 getByTestId が期待するのは  data-testid なので、画面自体は正常なのに要素が見つからずタイムアウトしてしまいました。これが分類Aのセレクターのズレにあたります。 これはAに分類されてるので、コード側の問題として testspec-to-code に差し戻され、コードを修正してもらっています。 その後修正と実行を繰り返し、最終的にはCの実装バグ疑いで人間にエスカレーションされました。実際、テストコードの問題ではなく、アプリ側の不具合だったため、コードを修正してもテストが通らず、3周しても解決しなかったため、人間に通知されて停止しました。 ここで見た通り、テストコードの生成と実行のフィードバックループが自動で回ることで、セレクターのズレやタイミング待ち不足といったコード側の問題は自動で修正され、実装バグや環境起因の問題は人間に通知してエスカレーションする、という流れができています。 おわりに 今回は、テスト仕様書の作成からコード生成、テスト実行、失敗した場合の原因切り分けと差し戻しまでを自動で回す E2E エージェントを紹介しました。 これを使ってE2Eテストを自動化して、ベルサッサしてハナキンをエンジョイしましょう。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AIエージェントが自分で直して再実行する〜Claude Code × Playwrightで作るE2Eテスト自走環境〜 first appeared on SIOS Tech Lab .

2026年6月10日未明（日本時間）、Anthropicが新モデル Claude Fable 5 を発表しました。（ 原文 ） Fable 5は、悪用リスクへの懸念から限定組織のみに提供されている上位モデル Mythosと中身が同じ で、違いは一部の危険領域タスクに制限がかかる点だけです。 発表の要点＋背景をまとめました。 概要 Fable 5 は、最上位モデルであるMythosを一般向けに安全化して公開したモデルです。 ポイントは3つです。 性能 :ほぼすべてのベンチマークで最高水準。タスクが長く複雑なほど他モデルとの差が開く。 安全設計 :サイバーセキュリティ・生物化学・蒸留などの高リスク領域だけ、Fableに代わって下位モデルが応答。発動は全セッションの5%未満で、 残り95%超は実質Mythos と同じ。 課金 : 本日から従量課金APIで利用可。サブスク勢は6/22まで無料利用可能、6/23以降は従量課金のみでの提供。余裕ができ次第、サブスク提供に復帰を目指す ざっくり、Mythosのこれまでの経緯 「Mythos」は、現状Claudeで最高性能モデルである、Opusの上に位置する最上位ティアの呼び名です。 その第1弾モデルとして2026年4月に登場したのが「Claude Mythos Preview」でした。 話題になったのは、性能の高さもさることながら、 サイバーセキュリティ能力が高すぎた ためです。 あらゆる主要OS・ブラウザの脆弱性を見つけてしまうほどで、悪用されれば重要インフラへの攻撃に使われかねない、という懸念から、一般公開されませんでした。 代わりにAnthropicは「Project Glasswing」という枠組みを立ち上げ、サイバー防衛側の組織や重要インフラ事業者など、限られた相手にだけMythosをPreview提供してきました。 「いずれ安全に提供できる体制が整えば一般公開したい」とは表明していたものの、これまでは触れられる人がごく一部に限られていた、というのがこれまでの状況です。 そして今回、その「安全に出せる体制」が整ったとして登場したのが Fable 5(= セーフガード付きの一般公開版)という経緯です。 Mythosはどれだけすごいのか まずは能力面です。同じ基盤モデルである Mythos 5 / Fable 5 が示した成果を見ると、世代の差を感じます。 ベンチマーク （画像: Anthropic公式発表より） どの領域でも大きく向上しています。   ソフトウェアエンジニアリング Stripeが、5,000万行に及ぶRubyコードベース全体の移行を1日で完了させたと報告。 手作業ならチーム全体で2ヶ月以上かかる規模で、 トークン効率も従来より改善 。 文書・分析業務 金融系のシニアレベル推論ベンチ(Hebbia Finance Benchmark)で全モデル中最高スコア。 文書ベース推論、図表の読み取り、問題解決で大きく改善。 画像理解 ビジョン系タスクでもトップの成績で、スクリーンショットだけからWebアプリのソースコードを再構築可能。 従来モデルが手こずった「ポケットモンスターファイヤーレッド」を、最小限の画面のみ構成でクリア。 メモリ・長文脈 数百万トークンにわたり集中を維持し、自分のメモを使って出力を改善。 デッキ構築ゲーム『Slay the Spire』では、ファイルベースの記憶を与えるとOpus 4.8の3倍の性能向上が見られました。 科学研究 創薬:タンパク質設計プロセスを約10倍に加速。人間の補助なしで熟練オペレーターに匹敵・凌駕し、14の標的中9つで有望な候補を発見。 分子生物学:新規かつ説得力のある科学的仮説を一貫して生成できる初のモデル。盲検比較で、科学者がOpusクラスより約80%の確率でMythosの仮説を支持。ある仮説は独立した研究で裏付けられた。 ゲノミクス:1週間超のほぼ自律的な作業で、138種・数百万細胞のデータを扱い、Science誌掲載モデルを100分の1のサイズで上回るMLモデルを設計・訓練。 「使える道具」というより「自律的に研究を進める存在」に近づいている、という点が従来との大きな違いです。 Fable と Mythos の違い Fable 5 と Mythos 5 は同じ基盤モデル です。違いはセーフガードの有無に尽きます。 Claude Fable 5 Claude Mythos 5 中身 同一の基盤モデル 同一の基盤モデル セーフガード あり(高リスク領域はOpus 4.8が代わりに応答) サイバー領域のセーフガードを解除 対象 一般ユーザー(誰でも) Glasswingパートナー等、審査を通った少数のみ 位置づけ 一般公開向けに安全化したMythos 世界最強のサイバー能力を持つフル性能版   Fableのセーフガードの仕組み 危険な使われ方を検知する専用の判定システムが、サイバーセキュリティ・生物化学・蒸留に関する要求を見つけると、Fable本体ではなく次点のOpus 4.8が代わりに応答します。（切り替わった場合はユーザーに通知されます） 安全優先で保守的に調整しているため、無害な要求を誤って捕捉することもありますが、Opus 4.8への切り替えが起きるのは平均で全セッションの5%未満です。 残り95%超のセッションでは切り替えが一切なく、その場合 Fable の性能は実質 Mythos 5 と同等になります。 3領域がカバーされる理由は、サイバーが脆弱性の発見・悪用を容易にしうること、生物化学がデュアルユース(防御にも攻撃にも使える)であること、蒸留が権威主義国での競合モデル訓練への流用を防ぐため、とされています。   ちなみに、これを執筆中にもFableを利用していたんですが、内容として特定文字列が含まれているせいか、勝手に下モデルに落とされました… 課金体系・利用方法 価格は 入力 $10 / 出力 $50(いずれも100万トークンあたり) です。Mythos Previewの半額以下になりました。APIでは claude-fable-5 を指定して利用します。 提供形態はプランによって異なるので注意が必要です。 API・従量課金型Enterprise 本日から完全に利用できます。 サブスクリプション(Pro / Max / Team / シートベースEnterprise) 段階的なロールアウトとなります。 〜6月22日 :追加費用なしで利用可。 6月23日〜 :対象プランからFable 5を外す。以降の利用には 使用クレジット(従量課金)が必要 。容量に余裕があれば無料期間を延長する可能性あり。 その後 : 十分な容量が確保でき次第、サブスクの標準機能として復帰させる方針。 できるだけ早く実施したいとのこと。 データ保持ポリシーの変更 新型攻撃の防御と誤検知の削減のため、Mythosクラス以上のモデルを企業利用(API経由など)する場合、 入力と出力がAnthropic側に30日間保存される ことが必須になります。 これはAnthropicのAPIを直接使う場合だけでなく、AWSやGoogle Cloudなど他社経由で利用する場合も同様です。 ただし、実際に影響を受けるのは、これまで「ゼロデータ保持(ZDR)」契約でデータを一切保存させない設定にしていた組織だけで、 個人プランや通常のTeam/Enterpriseプランはもともと標準の保持ポリシーで運用されているため、扱いは今まで通りで変更はありません 。 また、保存されたデータがモデルの訓練に使われることはなく、用途は安全対策に限定されます。人間によるアクセスも悪用の疑いがある場合などに限られ、すべて記録されたうえで、ほとんどの場合30日後に自動削除されます。   その他 今回の発表は、いくつかの動きと時期が重なっている点も押さえておくと理解が深まります。 ひとつは、Anthropicが公開市場への上場(IPO)準備を進めているとされるタイミングと重なっていること。 もうひとつは、同社が直前に「主要なAIラボは、フロンティアAI開発のスピードに協調してブレーキをかけるべき」と呼びかけおり、AIが人間の介入なしに自分自身を改良し続ける状態(RSI:再帰的自己改善)への懸念も表明しています。 つまり「これだけ強力なモデルを安全装置付きで世に出す」という今回の判断には、性能面のアピールだけでなく、そうした安全への姿勢を示す意味合いも重なっている、という見方ができます。 まとめ ついに、開発会社がこれ以上の開発は危ないと警鐘をならすほどのmythos級モデルが公開になりました。 性能面ではコーディングから科学研究まで明確な世代差があり、一方で利用にあたっては 6/23以降の課金切り替え と 30日データ保持の義務化 という運用上の変更点を押さえておきたいところです。 まずは6/22までの無料期間で、前に試してできなかったことや、より高度なタスクを試してみるのが良さそうです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【要点まとめ】ついに来た!最強AI、Mythosクラスが一般公開 ― Claude Fable 5 / Mythos 5 first appeared on SIOS Tech Lab .

SCANOSS サポート担当の橋本です。 弊社では SCA ツールのナレッジベース製品である SCANOSS 製品を代理店として取り扱っています。 SCANOSS 製品の開発元である SCANOSS 社より、SCANOSS 社内の Dependency-Track 運用ノウハウドキュメントを提供いただきました。 Dependency-Track は SCANOSS 製品と統合することが可能な OSS であり、SBOM の管理運用を実施する上で有用なソフトウェアであるため、本ドキュメントを翻訳の上公開いたします。 Dependency-Track を検討している方のお役に立てればと思います。 注：Dependency-Track は OWASP が開発している OSS です。 SBOM 運用のデファクトスタンダード的な OSS ツールではありますが、SCANOSS 社とは直接的な関係はございません。 本ドキュメントはあくまで SCANOSS 社が考える Dependency-Track ベストプラクティスという点にご注意ください。 1. 概要 (Overview) Dependency-Trackは、組織内の全プロジェクトにおけるコンポーネントの分析、監視、および制御を可能にする一元化されたダッシュボードを提供します。 CycloneDX 形式の SBOM および VEX(Vulnerability Exploitability Exchange) のインポート・分析を通じて、組織のポートフォリオ全体に含まれるすべてのアプリケーションのコンポーネント使用状況を追跡します。 2. SBOMアップロード後の脆弱性確認  プロジェクトのSBOMがアップロードあるいは更新されると、Dependency-Track は自動的に脆弱性分析を開始します。 監査の脆弱性 (Audit Vulnerabilities) タブへの移動 「監査の脆弱性」とは、各プロジェクトのコンポーネントに関する検出事項をトリアージするプロセスです。 特定のプロジェクト内で行われた監査の決定、コメント、および履歴は、そのプロジェクトの検出事項にのみ適用され、他のプロジェクトには影響しません。 プロジェクト監査には VULNERABILITY_ANALYSIS 権限が必要です。 監査証跡の閲覧は   VIEW_VULNERABILITY 権限を持つすべてのユーザーが可能です。 EPSS と重大度 (Severity) による優先順位付け 統合された EPSS (Exploit Prediction Scoring System : 脆弱性悪用予測スコア) を CVSS の深刻度と併用することで、どの検出事項から先に対処すべきかの優先順位を付けます。 「高い CVSS」＋「高い EPSS」＝即座に修正すべき項目、という判断基準になります。 脆弱性インテリジェンスソース Dependency-Track は、以下の7つの主要なソースと統合されています。 National Vulnerability Database (NVD) GitHub Advisories Sonatype OSS Index Snyk Trivy OSV VulnDB (Risk Based Security) 3. 監査判断の実施：分析ステート 各検出事項には分析ステートを割り当てます。 まず「設定されていません」の項目から着手し、調査中は 「トリアージ中」へ移行させ、最終的に調査結果に基づいたステートを決定します。 分析ステート一覧 日本語表記 英語表記 説明 設定されていません Not Set 分析がまだ開始されていない初期状態 悪用可能 Exploitable 脆弱性が悪用可能 (またはその可能性が高い) と判断された状態 トリアージ中 In Triage 検出内容の正確性や影響度を判断するための調査が進行中の状態 偽陽性 Falese Positive 誤ったロジックやデータ (コンポーネントの誤特定や脆弱性情報の誤りなど) による誤検知 影響を受けません Not Affected 脆弱性自体は存在する (真の陽性) が、当該プロジェクトの利用方法等により影響を受けない状態   ヒント： ステートの変更を含むすべての監査証跡には、ユーザー名とタイムスタンプが自動的に付記されます。 判断の根拠を後から検証できるよう、監査時には必ず具体的な理由をコメントとして記録してください。 4. ポリシー違反の確認 組織全体、または特定のプロジェクト単位でポリシーを設定し、ポリシー違反状況を継続的に測定できます。ポリシーの評価は、SBOM がアップロードされるたびに自動的に実行されます。 ポリシー違反には以下の 3 つの種類があります： I :ライセンス違反 宣言されたライセンスが組織のコンプライアンス基準に適合しているか確認します。 ポリシー管理 > ライセンスグループ > ライセンスグループの作成より「許容ライセンス」や「禁止ライセンス」といったライセンスグループを作成し、それらに対して違反条件を設定します。 承認済みリスト以外のものを検知するには、「『ライセンスグループ』『ではない』『許容ライセンス』」という条件を使用します。 禁止されているライセンスを検知するには、「『ライセンスグループ』『は』『禁止ライセンス』」という条件を使用します。 Copyleft などの一般的なライセンスグループは標準で用意されています。 ※訳注『』内は設定値です。 II:セキュリティ違反 脆弱性の重大度を条件として指定できます。 検出事項の重大度がポリシー条件と一致した場合、違反としてトリガーされます。 抑制れた脆弱性は、ポリシー違反を引き起こしません。 III.運用違反 以下の条件に基づき、特定のコンポーネントに対する許可・禁止ルールを作成できます。 年 : バージョン公開日からの期間 座標 : group, name, version (GAV) による特定 パッケージ URL (PURL) CPE SWID Tag ID ハッシュ値: MD5, SHA, SHA3, Blake2b, Blake3 バージョン距離: 使用中のバージョンと最新バージョンの差 これにより、特定のコンポーネントの許可リストや拒否リストを作成することができます。 5.影響範囲分析と特定 新しいCVE (脆弱性) が公開された際、ポートフォリオ内の 「コンポーネント (Component)」 または 「脆弱性 (Vulnerability)」 を活用することで、その影響を受けるライブラリを利用しているプロジェクトを検索可能です。 個別のプロジェクトを一つずつ確認する必要はなく、組織全体の影響範囲を迅速に評価できるため、影響範囲を即座に特定することができます。  活用シーン: ゼロデイ脆弱性への対応、監査、およびサプライチェーン・インシデントへの対応時。 6. 抑制 抑制機能は、検出事項をグローバル (ポートフォリオ全体) または特定のプロジェクト単位で非表示にするために使用します。 自環境のアーキテクチャ上、影響対象外であることが確認された脆弱性に対して使用します。 抑制された項目は、ダッシュボード上のポリシー違反カウントから除外されます。  抑制を行う前に、必ず監査コメントにその技術的・運用的理由を記録してください。 以前は適用外だった脆弱性も、デプロイメントやアーキテクチャの変更によって再度リスクとなる可能性があるため、定期的に抑制設定を再確認することが推奨されます。 https://docs.dependencytrack.org/triage/suppression/   7. 通知の自動化 ダッシュボードを手動で確認するのではなく、通知機能を活用してプッシュ型で情報の通知が可能です。 サポートされるチャネル Slack Microsoft Teams Mattermost Webhooks Webex Email Jira 推奨される通知トリガー 新規脆弱性の特定 (特に重大度が Critical または High のもの) ポリシー違反の発生 プロジェクト SBOM の更新 CI/CD 統合 Jenkins:   OWASP Dependency-Track Plugin を使用します。ポリシー違反が発生した際にパイプラインを自動的に失敗させることも可能です。 その他の CI システム:   REST APIを使用して SBOM をアップロードし、プログラムを介して違反の有無を確認します。   8. ベストプラクティス (Best Practices) SBOM の生成 SBOM は手動で作成せず、CI プロセス内で自動生成してください。 サプライヤーやベンダーに対しても、CycloneDX SBOM の提供を契約条件として要求してください。 商用ソフトウェアについても、可能な限り SBOM を入手または生成してください。 アナライザーとデータソース Internal Analyzer および OSS Index を有効化してください。 NVD および GitHub Advisories のミラーリングを有効化し、常に最新の知見を利用できるようにしてください。 日常の衛生管理 Dependency-Track 内のプロジェクトのバージョンを常に最新の状態に保ち、検出事項のスコープ (影響範囲) が正しく設定されるようにします。 ステートを変更する際は、毎回必ず監査コメント欄を使用してください。判断に至った経緯は、チームメンバーや監査人にとって非常に重要な情報となります。  個々のプロジェクトだけでなく、ポートフォリオのダッシュボードを定期的に確認し、全体的なリスクの傾向を把握します。 「プロジェクト収集 (Collection Projects)」を活用して関連するプロジェクト (例：チームや製品ライン別など)をグループ化し、集約されたビューで確認できるようにします。 「トリアージ中 」 の状態で長期間放置されている検出事項に対処するため、定期的なレビューのサイクル (例：週次でのトリアージセッションなど)をスケジュールします。   9. チュートリアルビデオ (Tutorial Videos) タイトル とリンク 説明 OWASP Spotlight: Project 15 — Dependency-Track OWASP 財団による概念的概要 — ステークホルダー向け Tool Review: DependencyTrack   インストール、ダッシュボード、API キー、プロジェクトの作成とインポートについて説明 OWASP Flagship Projects: Dependency-Track — Steve  Springett プロジェクト作成者による解説：ビジョンと設計思想 OWASP DependencyTrack Walkthrough UI のクイックデモ (簡単な実演) — 主要な画面説明 OWASP Dependency-Track SBOM Analysis Up and Running in Minutes ステップバイステップの設定手順、および SBOM 自動アップロードのための GitHub Actions 連携 Understanding Open Source  Dependencies — Lightning Talk (Fran Hoey)  コミュニティ・カンファレンスでの講演：日々の利用に役立つ実用的な事例 Is Your Supply Chain Safe? Dependency-Track Tutorial for Devs  CycloneDX SBOM の生成とサプライチェーン・リスク評価を説明 10. 公式チャネルと主要ドキュメントリンク YouTube の公式チャネルでは、メンテナによる新機能解説やコミュニティミーティングを含む約 30 本のビデオが公開されています。 継続的なアップデート情報を得るため、サブスクライブを推奨します。  https://www.youtube.com/c/OWASPDependencyTrack 主要ドキュメントリンク 監査の基本  https://docs.dependencytrack.org/triage/auditing-basics/ 分析ステート https://docs.dependencytrack.org/triage/analysis-states/ 抑制 https://docs.dependencytrack.org/triage/suppression/ ポリシーへの準拠  https://docs.dependencytrack.org/usage/policy-compliance/ 影響分析 https://docs.dependencytrack.org/usage/impact-analysis/ CI/CD連携 https://docs.dependencytrack.org/usage/cicd/ ベストプラクティス  https://docs.dependencytrack.org/best-practices/ REST API  https://docs.dependencytrack.org/integrations/rest-api/ 通知  https://docs.dependencytrack.org/integrations/notifications   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Dependency-Track：日常運用ガイド first appeared on SIOS Tech Lab .

こんにちは、サイオステクノロジーの藤井です。 生成AIのテクニックとして、システムプロンプトに「あなたは優秀なエンジニアです」みたいなペルソナを付けるっていう方法聞いたことありませんか？ それで、ある日ふと疑問に思ったのですが、「優秀な」っていらなくないですか？ だって、「優秀な」ってつけるだけで優秀になるなら「とても優秀な」ってつけたらもっと優秀になるし「超ウルトラスーパー優秀な」ってつけたら超ウルトラスーパー高性能AIになるわけですよね？そんなわけなくね？ ということで軽く調べてみました。 すると、そもそも「ペルソナには効果が無い、どころか悪影響である」という衝撃的な記事を見つけました。 ほんとかよと思ったので、実際に検証して確かめてみました。 先行研究について ペルソナプロンプティングの効果については、研究者の間でも意見が分かれているようです。調べた範囲で整理してみました。 肯定的な研究 Li et al. の “Large Language Models Understand and Can be Enhanced by Emotional Stimuli”（2023年7月）では、プロンプトに「This is very important to my career」のような感情的刺激を追加すると、GPT-4やLlama 2などで8〜115%の性能改善が見られたとしています。 Xu et al. の “ExpertPrompting”（2023年5月）では、詳細にカスタマイズされた専門家の背景を自動生成し、その専門家として回答させることで品質が向上したと報告されています。 懐疑的な研究 一方で、効果に否定的な研究も多くあります。 Zheng et al. の “When ‘A Helpful Assistant’ Is Not Really Helpful: Personas in System Prompts Do Not Improve Performances of Large Language Models”（2023年11月）は、162種類のロール × 2,410問で評価した結果、ペルソナの効果はほぼランダムだったと報告しています。2023年の時点で既に懐疑的な結果が出ていたということです。 Basil, Mollick et al. の “Playing Pretend: Expert Personas Don’t Improve Factual Accuracy”（2025年12月）は、6モデルをGPQA DiamondとMMLU-Proで評価した結果、ドメイン内の専門家ペルソナでも有意な改善がなかったと報告しています。逆に、素人や幼児のような低知識ペルソナでは精度が悪化しました。 Bai, Holtzman, Tan の “‘You are a brilliant mathematician’ Does Not Make LLMs Act Like One”（2025年10月）は、タイトルがそのまま今回の問いに対する答えになっています。数学・心理学・法律の3ドメインで検証した結果、「否定ペルソナ」（あなたは数学者ではありません）が肯定ペルソナと同等以上のスコアを出し、ドメインプライミング（「これは数学の問題です」）が最も安定していたとのことです。 Hu, Rostami, Thomason の “Expert Personas Improve LLM Alignment but Damage Accuracy”（PRISM, 2026年3月）は、ペルソナがアライメント（人間の好みとの一致度）を改善する一方で精度を損なうことを示しました。タスクの種類によって効果が逆転するという結果です。 研究によって結論が違うのは、タスクや評価指標やモデルの違いが大きそうです。せっかくなので自分でもやってみることにしました。 実験設計 5つのペルソナ条件 実験では、システムプロンプトに設定するペルソナを5パターン用意しました。 条件 システムプロンプト 意図 P0: 中立 「ユーザーの質問に回答してください。」 ベースライン P1: 役割のみ 「あなたはソフトウェアエンジニアです。」 役割付与の効果 P2: 形容詞付き 「あなたは 優秀な ソフトウェアエンジニアです。」 形容詞の上乗せ効果 P3: ドメインプライミング 「以下はソフトウェアエンジニアリングに関するタスクです。」 人ではなくタスクを修飾 P4: 否定 「あなたはソフトウェアエンジニアではありません。」 否定した場合の影響 先行研究で指摘されていた「ドメインプライミング」をP3として独立させてみました。 ベンチマークと評価方法 ベンチマーク 概要 問題数 評価方法 MMLU（CS系） コンピュータサイエンスの知識問題 250問 4択一致 HumanEval Pythonのコーディング問題 164問 テストケース通過 MATH Level 4–5 高校〜大学レベルの数学 250問 \boxed{} 値一致 モデルは gpt-5.4-nano、temperature=0で固定しました。 実験結果 全体結果 各ベンチマークの正答率 ペルソナ MMLU HumanEval MATH 平均 P0 中立 64.4% 79.9% 54.0% 66.1% P1 役割のみ 65.6% 79.9% 51.2% 65.6% P2 形容詞付き 64.0% 78.7% 53.2% 65.3% P3 ドメインプライミング 64.8% 82.9% 54.8% 67.5% P4 否定 63.6% 79.9% 53.6% 65.7% 全体の傾向としては、P3 > P0 > P4 > P1 > P2 とドメインプライミングが最も正答率が高くなりました。 ペルソナ有りはペルソナ無しより正答率が低く、「優秀な」をつけたペルソナではさらに低くなりました。 とはいえ、あまり大きな差ではなく、今回の問題数だと誤差の可能性も十分にあります。 考察 この結果をどう解釈すべきか、3つの観点で整理してみます。 ペルソナはフィルター（スタイル変更）であり、能力向上ではない。 ペルソナを設定すると回答のトーンや形式は変わります。しかし、正答率という意味での「能力」は統計的には改善しませんでした。むしろ、凝ったペルソナを付けるほど微減する傾向すらあります（P0: 66.1% → P1: 65.6% → P2: 65.3%）。これは PRISM の「アライメントは改善するが精度を損なう」という知見とも一致します。 ドメインプライミング（P3）がわずかにプラス傾向。 今回の実験でも P3 は平均 67.5% と最も高く、特に HumanEval で 82.9% を記録しました。統計学的な有意差には至っていませんが、Bai et al. の「ドメインプライミングが最も安定」という知見と一致しています。ペルソナ（人に対する修飾）よりも、タスクに対する修飾のほうが方向性を定めやすいのかもしれません。 「優秀な」は曖昧すぎて、条件付き生成の方向を定められない。 「優秀な」と言われても、何をどう優秀にすればいいのかモデル側で解釈しようがありません。結果として有意な改善は生じず、むしろ微減する傾向がある、というのは納得できる話です。 実践的な結論 実験結果と先行研究を踏まえて、プロンプトの書き方を整理しました。 書き方 評価 理由 「あなたは優秀なエンジニアです」 曖昧な形容詞は無意味。むしろ微減する可能性がある 「あなたはエンジニアです」 出力のスタイルは変わるが、精度改善にはつながらない 「このタスクはPythonのasyncioに関する問題です」 ドメインプライミング。タスクの文脈を明示する 具体的な制約や文脈を与える ExpertPromptingの本質。「優秀」ではなく「何をどう解くか」を伝える プロンプトに書くべきは「あなたが何者か」ではなく「このタスクが何であるか」です。ペルソナに形容詞を積むよりも、具体的な制約条件や期待する出力形式を書いたほうが生産的だと思います。 余談 最後に、実験中に気づいた副産物を書いておきます。 temperature=0でもシステムプロンプトだけで回答が結構変わる。 temperature=0(決定的出力の設定)にしていますが、MMLUの20.8%、MATHの32.4%の問題でペルソナ間で回答が異なりました。ペルソナによって回答の内容には影響していますが、正答率の方向には効いていない様です。 「エンジニアではありません」と否定しても正答率は落ちない。 P4（否定ペルソナ）の正答率は65.7%で、P0（中立）の66.1%とほぼ同じです。「あなたはエンジニアではありません」と言われても、エンジニアリングの問題は普通に解けていました。 実務タスクでも差は出なかった。 ベンチマークだけでなく、実際のシステム企画書のレビューでも試してみましたが、条件間で目立った差はありませんでした。(ただし、この試行はモデルに対してタスクが難しすぎたかもしれません) この記事で書いたこと 生成AIのペルソナに効果はあるのか、また、「優秀な」の様な形容詞をペルソナに付けることは有効か実験した 先行研究は肯定と懐疑に分かれており、今回の実験結果は懐疑側の知見と一致した 「あなたは優秀なエンジニアです」のような形容詞付きペルソナで精度改善は見られず、むしろ微減する傾向があった 5ペルソナ × 3ベンチマーク（3,320回）の実験で、条件間の差は大きくても4%程度。誤差の可能性も十分にある ドメインプライミング（P3）だけがわずかにプラス傾向を示した プロンプトには「あなたが何者か」より「このタスクが何であるか」を書くほうが良さそう 参考文献 Li et al. (2023). “Large Language Models Understand and Can be Enhanced by Emotional Stimuli.” arXiv:2307.11760 Xu et al. (2023). “ExpertPrompting: Instructing Large Language Models to be Distinguished Experts.” arXiv:2305.14688 Zheng et al. (2023). “When ‘A Helpful Assistant’ Is Not Really Helpful: Personas in System Prompts Do Not Improve Performances of Large Language Models.” arXiv:2311.10054 Basil, Mollick et al. (2025). “Playing Pretend: Expert Personas Don’t Improve Factual Accuracy.” arXiv:2512.05858 Bai, Holtzman, Tan (2025). “‘You are a brilliant mathematician’ Does Not Make LLMs Act Like One.” OpenReview Hu, Rostami, Thomason (2026). “Expert Personas Improve LLM Alignment but Damage Accuracy.” arXiv:2603.18507 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post AIにペルソナ設定は効果ないって本当？検証してみた first appeared on SIOS Tech Lab .

PS SLの佐々木です。 Claude Code のOpus4.8を使っていると The model's tool call could not be parsed が頻発するようになりました Turn failed — Try sending your message again. The model’s tool call could not be parsed (retry also failed). 「なぜ起きるのか」「どう避けるのか」は、claude-code の GitHub リポジトリに立てられた一連の Issue を読んでみたのでまとめ記事になります。 概要 最初に押さえておきたいのは、これがユーザー側のコードや設定の問題ではなく、 Opus 4.8（および一部 4.7）側のリグレッション として報告されています。 複数の Issue で共通して指摘されているのは、同じワークフローでもモデルを Opus 4.7 や Sonnet 4.6 に切り替えるとエラーが止まるようです。つまりハーネス（クライアント側）の不具合ではなく、特定モデルのリグレッションとして切り分けられています。 根本原因： <invoke> テキストとして吐かれてしまう この問題を最も丁寧に分析しているのが Issue #64658 （デスクトップアプリの Code タブからの報告）です。 stop_reason: tool_use のターンにおいて、モデルが構造化された tool_use ブロックではなく、レガシーな <invoke> 形式の XML テキストとして tool call をシリアライズしてしまう。このとき、余計なトークン（ court / count のような）が混ざったり、本来必要な antml: プレフィックスが落ちたりすることがあり、結果としてパーサが解釈に失敗する。 これを API レイヤの視点から裏付けているのが Issue #61133 になります。Anthropic API の仕様上、 stop_reason: tool_use のレスポンスには必ず tool_use ブロックが含まれていなければならない。ところが Opus 4.8 では、 stop_reason: tool_use を返しながら tool_use ブロックが1つも入っていないターンが断続的に発生する、と報告されている。中身のない tool_use ターンがエラーの引き金になっているわけだ。 なぜ「retry also failed」になるのか エラーメッセージの末尾に付く (retry also failed) も、Issue を読むと理由が報告されています。 Issue #64235 によれば、最初の失敗時にハーネスは「ツールコールが壊れていた、リトライせよ」という旨のメッセージを注入して再試行する。ところがこのリトライが 同じコンテキストをそのまま再送する ため、モデルは同じ壊れ方を再生産し、当然また失敗する。1回限りのリトライが構造的に成功し得ない設計になっている、という指摘がされていました。 さらに #64235 では、tool が実際にはすでに実行されて結果を返しているのに、その次のターンで malformed エラーが発火し、ラウンドが無駄になるケースも報告されています。ユーザーから見ると「しばらく考えた末に何もせず黙り込んだ」ように見える、という記述が状況をよく表しているようです。 発生条件 「なんとなくランダムに起きる」ように見えるが、発生条件は複数の Issue でかなり絞り込まれている。 長いマルチバイト / CJK 文字列の引数（ #64506 ）。 ツールコールの引数に長い日本語・中国語などのマルチバイト文字列が含まれるとパースが失敗する、という切り口で立てられた Issue。日本語環境での開発はこの条件に当たりやすい。 プレーンテキスト化（ #64418 ）。 「高コンポジションなセッション」、つまり情報量の多いセッションで、tool call が tool_use ブロックではなくプレーンテキストとしてシリアライズされる、という Issue。前述の根本原因と同じ現象を別角度から報告している。 大きいコンテキスト・広いツール面（ #64235 , #63687 ）。 1M コンテキストモードで、複数の MCP サーバや多数の skill を積んだ巨大プロンプトのとき、失敗率が上がるという相関が報告されている。#63687 では「ツール自体は成功しているのに malformed エラーが出る」点が強調されている。 長い thinking ブロック（#64235）。 effort レベルを高く設定して長考させると、失敗したターンの直前には必ず thinking ブロックがある、という観察。長考とツールコールのシリアライズの相互作用が疑われている。 整理すると「長い CJK 引数 × 大きいコンテキスト × 長考」が重なるほど踏みやすいということが分かります。日本語まじりの設定ファイルや長いログを扱う作業は、この条件にハマりやすい部類になるので注意が必要そうです。 回避方法（Issue 記載のもの） #64658 には、影響を受けているユーザー向けの回避策が明記されています。 モデルを Opus 4.8 から Opus 4.7 または Sonnet 4.6 に切り替える 。 malformed なターンを含むセッションを resume せず、新規セッションを始める 。 1M コンテキストモードを避ける・積んでいる MCP や skill を減らす・thinking の effort を下げる、といったプロンプトを軽くする対策も発生率の低下に寄与する。 クライアント側で取り得る恒久対策の提案もされている。リトライ時に失敗した直前のアシスタントターンをそのまま再送しない（あるいは漏れた <invoke> テキストを除去してから送る）、 stop_reason: tool_use かつ tool_use ブロックが0個のケースを検知してテキスト中の <invoke name="..."> をパースするフォールバックを用意する。 現状：未解決 これらの Issue を通読して分かるのは、本記事執筆時点で まだ解決していない ということのようです。#64658 では最新のデスクトップアプリビルドでも再現することが確認されており、関連 Issue の多くが Open のまま、あるいは duplicate として集約されている状況となっています。 バージョンを上げるだけでは直らないため、当面はモデル切り替えと新規セッションでの再開という回避策で凌ぐのが現実的な対応のようですね。。。 参照した一次情報 #64658 — Desktop app (Code tab) 1.9659.4: Opus 4.8 でなお再現／根本原因と回避策のまとめ #64506 — 長いマルチバイト / CJK 文字列引数でツールコールのパースが失敗 #64418 — Opus 4.8: tool call が tool_use ブロックでなくプレーンテキストとして出力される #64375 — Claude 4.8 Opus での頻繁なツール実行エラー #64235 — 2026-05-29 以降のリグレッション／retry が同一コンテキストで失敗 #64176 — 2.1.150〜2.1.158 のバージョン二分探索（リトライ耐性のあるリグレッション） #63687 — Opus 4.8 (1M context): ツールは成功しているのに malformed エラーが頻発 #61133 — Opus 4.7: stop_reason=tool_use なのに tool_use ブロックが無い（2026-05-20 以降） ※ これらは継続調査中の報告であり、状況は今後のアップデートで変わる可能性があります。最新の状況は各 Issue を直接ご確認ください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Opus4.8で The model’s tool call could not be parsed が頻発している件 first appeared on SIOS Tech Lab .

ども！最近 .claude/skills/ の中身が増えすぎて整理に追われている龍ちゃんです。 スキルって、増えてくると 狙ったやつが発火しなくなる んですよね。ぼくの .claude/skills/ はいま 15 個くらい。とくにレビュー系が 5 個ほど並んだ頃から、しっかり指示しないと違うレビューが走るようになって、「レビューして」の一言がもう信用できなくなりました。 今日は、その問題を 複数のスキルを 1 つの “ルーター” に集約して、発話で振り分ける ようにして解決した話をします。スキルを消して減らすんじゃなくて、束ねて減らす。このプロジェクトのレビュー系スキルで、実際にやったやつです。 スキルが増えるほど誤発火する：budget は静かに削れていく そもそも、なんでこんなに増えたのか。レビュー観点を思いつくたびに、スキルを 1 個ずつ足していったからです。技術的な正確さ、文章の質、SEO、競合比較……「観点が 1 個 ＝ スキルが 1 個」でやっていたら、レビュー系だけでみるみる膨らみました。 そして、痛みが 2 つ出てきます。 1 つめは、 表に出る痛み＝誤発火 。似た description が並ぶと、Claude Code がどれを動かすか迷うんです。「レビューして」と言っても狙ったのと違うレビューが走る。毎回しっかり指示を足さないと、思ったスキルが発火しない。ただこれは、動いた結果が変だからすぐ気づけます。 2 つめは、 気づけない痛み＝character budget 。スキルの description は常時コンテキストに積まれていて、スキルが増えるほど膨らみます。そして budget を超えると、Claude Code は description を自動で切り詰める。マッチに必要なキーワードごと削られて、 自分は何も変えていないのに、ある日スキルが静かに発火しなくなる （ 公式ドキュメント にも “descriptions are shortened to fit the character budget, which can strip the keywords Claude needs to match your request” と明記された挙動です）。 /doctor を叩けば budget 超過と影響スキルは見えますが、意識しないと気づけません。誤発火と違って「壊れたことにすら気づきにくい」のが、こっちのタチの悪いところです。 budget の文字数や仕組みを深掘りすると長くなるので、ここでは「個数が増えると description が削られて発火が劣化する」という前提だけ。詳しくは 別記事「『Skill listing will be truncated』の正体と直し方」 で。 表の痛みも裏の痛みも、根っこは同じ「スキルの個数」でした。だったら、個数そのものを減らせばいい。冒頭で言った “束ねて減らす” を、ここから具体的に見せていきます。 文脈で束ねる ＝ ルーター Skill ルーター Skill の役割は 自分で処理しないこと 。発話の修飾語を読んで、適切な sub-agent を選び、 Agent tool で起動するだけです。 ポイントは、 スキルの description は常時コンテキストに載り、 character budget を食う ということ。スキルが N 個あれば N 個分が積まれ、似た発火条件どうしが競合して誤発火します。ルーターにすれば、スキルとして登録するのは 1 個です。常時載る description も 1 個分 に減ります。各機能のロジックは呼ばれたときに 別コンテキストで動く agent へ、ナレッジは必要なときだけ読む references へ逃がしてあるので、ルーター本体（＝常時載る description）は薄いまま保てます。 つまり、 発火条件を 1 つに統合したから誤発火が消え、常時載る description が N→1 に減ったから budget が空く 。この 2 つは別々の効果じゃなくて、「発火条件＝description を 1 つにまとめた」ことの裏表なんですよね。 具体例で見てみましょう。僕が束ねたのはブログ記事のレビュー系でしたが、仕組みはどんなレビューでも同じです。なのでここは、エンジニアに一番馴染むであろう コードレビュー で説明します。 セキュリティ・パフォーマンス・フロント・バックエンド……観点ごとに別々のスキルを作る代わりに、1 つの code-review ルーターにまとめて、発話で呼び分ける。こんなイメージです。 --- name: code-review description: | コード (src/**) を編集している文脈で発火するレビュー router。 「レビューして」「セキュリティ見て」「フロントだけ」「バックだけ」 「パフォーマンス見て」「全部見て」等の発話で発火する。 発話の修飾語から起動する sub-agent を選択し、Agent tool で並列起動する。 allowed-tools: Read, Glob, Agent --- 発話に含まれる語 起動する sub-agent （修飾なし）「レビューして」 security + performance + readability（並列） 「セキュリティ見て」 security-review のみ 「フロントだけ」 frontend-review のみ 「バックエンドだけ」「API だけ」 backend-review のみ 「パフォーマンスだけ」 performance-review のみ 「全部見て」 用意したレビュー全部を並列 「レビューして」だけで 3 エージェントが並列で走る！これが Slash Command 単体にはない強みです。スラッシュコマンドは 1 回の呼び出しで 1 つの処理ですが、ルーター Skill は複数 sub-agent を同時に走らせられます。 以前書いた「 Claude Codeのドキュメント検索を極力さぼれるようにした話 」も、サブエージェントに処理を委譲して use_when で呼び出す設計で、考え方が重なります。 ロジックは agent へ、ナレッジは references/ へ ルーター SKILL.md 自体は 薄く保ちます 。そして束ねるのは sub-agent だけじゃありません。 「どう処理するか」のロジックは agent へ、「何を見るか・どう使うか」のナレッジは references/ 」と、役割で 3 層に分けます。 ルーター SKILL.md（薄く）── 発火条件 + 修飾語 → 振り分けだけ ↓ 呼び出す .claude/agents/*.md ──────── 処理のロジック本体 ↓ 必要なときだけ読む skill/references/ ────────── ナレッジ（観点リスト・チェックリスト・使い方手順） たとえば security-review なら、「見るべきセキュリティ観点」のチェックリストを references/ に置いておく。agent はそれを必要なときだけ読みにいきます。観点を足したいときは references を 1 ファイル直すだけです。SKILL.md にも agent 本体にもベタ書きしないから、常時のコンテキストは増えないし、ナレッジの管理も一箇所で済むんですよね。 ちなみに、 処理を全部 agent に渡す必要はありません 。「ここはメインの会話の流れのまま、途中を見ながら進めたい」という処理もありますよね。そういうときは agent に移譲せず、手順を references/ に書いておいてルーター自身（メインコンテキスト）に実行させる。こうすれば、今までメインでやっていた作業を、使用感を変えないままルーターに取り込めます。agent に切り出すか、references の手順としてメインで回すかを処理ごとに選べる、ということですね。 この「使うときだけ読み込まれる」挙動は、公式でいう Progressive Disclosure です。仕組みの詳細は公式に譲りますが、 references をいくら厚くしても、常時のコンテキストは太らない 。だから観点もチェックリストも手順も、遠慮なく references 側に積んでおけるんですね。 で、束ねたら何が変わったか 狙ったスキルがちゃんと発火する。これが当たり前にできるようになりました。スキル発火後にワンアクションが必要になりましたが、面白いのはその先です。 ルーターのほうから提案してくるようになった んですよね。文脈を読んで「これ、レビューしときましょうか？」と向こうから振ってくる。意図どおりならそのまま「お願い」で済むし、こっちが思いついてなかった使い道まで「こういうのにも使えますよ」と教えてくれる。おかげでレビューを頼むときの解像度がぐっと上がりました。雑に「レビューして」と投げても、文脈に合ったやつが返ってくるんです。 あと、これは完全に狙ってなかった副産物なんですが、 メンテも楽になりました 。 束ねる前は、スキルを名前のプレフィックスで分類していました。 review-xxx 、 blog-xxx 、みたいに。でもこれ、いざ「この観点を直して、その知見をあっちにも反映したい」となったとき、関連ファイルがパスのあちこちに散っていて「どれとどれを見ればいいんだっけ」になるんですよね。ルーターにしてからは「レビュー関連はこの 1 か所」と文脈でまとまっているので、直したいものも、関連する作業も、一発で辿れる。情報の在処がはっきりしました。 ルーターにすべきか、独立スキルのまま置くか — 判断軸 集約すべきかどうかは 1 問で判断できます。 発火する文脈と修飾語が共通か？ YES なら集約候補です。 目的が近い（レビュー系・調査系・変換系） 同じファイル文脈で発火する（「ブログ記事を編集中」など） 修飾語で選べる（「ぶった切って」「論理だけ」のように呼び分けられる） NO なら独立スキルのまま置いていいです。 発火する文脈がまったく違う 単独で完結して他と競合しない 過剰集約の罠にも触れておきます。何でも 1 つに詰めると description が「全部入り」で逆に曖昧化して、発火精度が落ちるんですよね。ルーターは「文脈」で束ねるのが基本で、無関係な機能を 1 個に混ぜるのは逆効果です。 判断早見表をまとめると： 条件 判断 発火文脈が同じ（例：ブログ編集中） ルーターに集約 修飾語で呼び分けられる ルーターに集約 目的が近い（レビュー系、調査系…） ルーターに集約 発火文脈がバラバラ 独立スキルのまま 単独で完結、競合しない 独立スキルのまま description が「全部入り」で曖昧になる 過剰集約。文脈で分割 「スキルを消す前に、束ねられないか」まずは /skills で一覧を出して、「これ全部、同じ文脈で呼んでるな」という似たグループを探してみてください。見つかったら、そこがルーターの出番です。 ほなまた〜 関連記事 Claude Code への指示を少しでもさぼりたい！AskUserQuestion ツール — ルーターの原型となった review-article スキル Claude Codeのドキュメント検索を極力さぼれるようにした話 — サブエージェントに検索を委譲し、use_when で呼び出す設計 GitHub Actions 失敗ログ、まだ手動で読む？Copilot Agent Skills で CI デバッグ を自動化する実装ガイド — references/ 参照で 1 SKILL.md に集約した例 Claude Code:「Skill listing will be truncated」の正体と直し方 — スキルを消さず description を「外す／縮める」で character budget を解消する対症療法（ disable-model-invocation ・薄い description） CLAUDE.md 効かない？ドメイン注入を設計思想から見直す Claude Code: 公式 MCP を補完する Skills 設計パターン ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Code スキルの誤発火を防ぐ「ルーター集約」設計 first appeared on SIOS Tech Lab .

「Skill listing will be truncated」という赤文字が出た（起動時の警告） ある日 Claude Code を立ち上げたら、見慣れない赤文字が出ていた。 Skill listing will be truncated 何これ。Skill、壊れた？ 3 ヶ月ぶりのブログ復帰、龍ちゃんです。この 3 ヶ月で .claude/ に Skill だの Command だのを作りまくっていたら、起動時にこの赤文字が出るようになっていました。 color: warning の黄色〜赤系で出るやつですね。最初は「設定をミスったか」と思ったんですが、調べてみたら 仕様どおりの正常な警告 でした。 というのも、僕は「Skill は作ったらとりあえず .claude/skills/ にぶっこむ」というスタンスでやってきたんですよね。で、気がつけばかなりの数になっていました。この進め方自体、最初の一歩としては結構よかったと思っています。ただ、その数が積み上がってきたところに、ダメ押しみたいにこの赤文字が出た、というわけです。 結論から言うと、これは character budget という仕組みからの SOS で、対処は「Skill を削除する」ことでも「budget を引き上げる」ことでもなく、 description を “削減” する ことでした。順番に話します。 今回の内容です。 この赤文字（ Skill listing will be truncated ）の正体は何か 実は警告は 2 種類あって、意味がまったく違うという話 budget を上げる対症療法ではなく、”削減” で対処する 2 つの手段 赤文字の正体は character budget の超過だった 調べた結論を先に言うと、この赤文字は character budget （Skill 一覧の文字数予算）を超えたときに出ます。公式ドキュメント（ Extend Claude with skills – Claude Code Docs ）に明記されている仕様です。 budget の計算式と「1,536 文字の壁」（公式仕様） Skill の description は、Claude が「どの Skill が使えるか」を知るためにコンテキストへ読み込まれます。その総量に予算（budget）があって、こう決まっています。 character budget = コンテキストウィンドウ × 1% The budget scales at 1% of the model’s context window. ちなみに以前のバージョンには「8,000 文字の下限」もあったんですが、現行の公式 Docs ではこの記述が消えて 1% のみになっています。最近のモデルなら 1% でだいたい 1.5 万文字ぶんくらいなので、実質この 1% が効いてくる感じですね。 そして、個別の Skill ごとにも上限があります。 description と when_to_use の合計が 1,536 文字 で打ち切られます。 the combined description and when_to_use text is truncated at 1,536 characters in the skill listing to reduce context usage. 予算を超えるとどうなるか。description が短縮されます。ただし name （Skill 名）だけは常に残ります。 All skill names are always included, but if you have many skills, descriptions are shortened to fit the character budget. つまり、 自分は Skill を覚えているのに、Claude 側は description のキーワードを失っている わけですね。 Skill 警告は 2 種類：「shortened」と「truncated」の違い これ、調べてみたら Claude Code の警告って 2 種類 あって、意味がまったく違うんですよ。（Claude Codeのバイナリ探索談！） 実際に、僕の環境で動いている Claude Code（v2.1.162）の本体バイナリを Claude 自身に探索してもらったら、警告文を出し分けているこんなコードが見つかりました。 let v = K ? "Skill listing will be truncated" : "Some skill descriptions will be shortened"; // color:"warning" で描画、"N/M chars" の予算表示を伴う 整理するとこうです。 警告文 発火条件 何が起きるか Some skill descriptions will be shortened 個別の 1,536 文字 cap を超過 description が 短縮 される（全 Skill は一覧に残る） Skill listing will be truncated budget（コンテキストの 1%）を超過 低頻度の Skill の description が まるごと消える 僕が見たのは後者の truncated の方でした。予算全体が足りなくなって、低頻度の Skill の description がごっそり落ちる——要は Skill が一覧から実質見えなくなるやつですね。前者（ shortened ）はもっと軽くて、個別の description が長すぎて切り詰められるだけなので、Skill 自体は一覧に残ります。 同じ赤文字でも深刻度がぜんぜん違う んですよね。 放置すると「呼びたい Skill が来ない・別のが誤発火する」 で、truncated で description が落ちると、何が起きるのか。ここからは調べた挙動から考えられる「起こりうる症状」の話です。 Claude は description のキーワードを手がかりに「どの Skill を使うか」を判断しているので、それが欠けると次のようなことが起きる可能性があります。 呼びたい Skill が反応しない ：キーワードが落ちて、Claude がマッチできない 別の Skill が誤発火する ：description が残っている別の Skill が拾われる 「最近 Skill の挙動が安定しないな」という人は、一度 /doctor を叩いてみてください。budget がどれくらい溢れているか、どの Skill が影響を受けているかが見えます。 どの Skill から落ちるかは公式 Docs に明記があって、budget を超えると 使用頻度の低い Skill の description から先に落ちる 仕様です（”descriptions for the skills you invoke least are dropped first”）。よく使う Skill はフルで残るので、 name だけになって description が消えるのは普段あまり呼んでいない Skill の方なんですよね。 budget 引き上げは最終手段、まず description を “削減” する で、どう対処したかなんですが。 まず、すぐ思いつくのは budget を引き上げる 方法です。 skillListingBudgetFraction （settings.json、例 0.02 = 2%）や環境変数 SLASH_COMMAND_TOOL_CHAR_BUDGET で予算枠を広げられます。 ただ、これは 最終手段 かなと思っています。budget を広げても Skill が増え続ければまた頭打ちになるし、枠を広げた分だけコンテキストも食いますからね。予算に手を入れる前に、まず見直すべきは Skill 側 の “使われ方”。そこを整理して description を「削減」する、というのが本筋なんですよね。 今回紹介するのは、その Skill 側に手を入れる削減です。やり方は 2 つあって、description を budget から 外す か、 縮める か。順に見ていきます。 前提：Skill と Slash Command はもう同じ仕組み 1 つだけ前提を。かつて 「発火しないなら Slash Commands に移す」 としていた頃は、Skill と Slash Command は別の仕組みでした。でも今は 両方が同じ Skill システム上で動作 するよう 統合されました 。公式 Docs にも “Custom commands have been merged into skills.”（カスタムコマンドは Skill に統合された）と明記されていて、 .claude/commands/deploy.md と .claude/skills/deploy/SKILL.md はどちらも同じ /deploy として同じように動く、と書かれています。自動発火するかどうかといった挙動は frontmatter で決まります。だから「ファイルを別ディレクトリに移す」必要はなく、frontmatter をいじるだけで済みます。これが次の話の土台です。 削減①：disable-model-invocation で budget から「外す」 1 つめは、そもそも description を予算に乗せない方法。frontmatter に 1 行足すだけです。 --- name: my-skill description: 何をする Skill か disable-model-invocation: true # ← この 1 行 --- 公式に記載されている効果はこうです。 Description not in context, full skill loads when you invoke. これで何が起きるかというと、 description が character budget から 完全に除外 される（＝最大の削減） Claude の自動発火が止まる（誤発火事故の防止） /skill-name での手動呼び出しは可能（ / メニューに残る） 本文は呼び出し時のみロード（コンテキスト効率は維持） ディレクトリ移動なし、ファイル削除なし。frontmatter 1 行で「自動発火しない・手動でだけ呼べる」状態になります。これが “実質 Commands 化” です。 対象は、 人間が発火タイミングを完全に制御したい Skill 。副作用がある（commit / deploy / 送信）、特定の作業でしか使わない、手癖で /foo を打っている——こういう Skill に description は要りません。 削減②：薄い description で「縮める」 2 つめは、自動発火に価値がある Skill 向け。これは消さずに残しますが、 description を 1,536 文字フルに使う必要はない 。 ここで 1 つ注意。さっき「キーワードが落ちると Claude がマッチできない」と言ったので、「薄くしたら発火しなくなるのでは？」と不安になるかもしれません。でも 削るのは “この Skill が何をするか” という機能説明のほうで、”どんなときに呼んでほしいか” というトリガーキーワードはむしろ残す 。ここを取り違えなければ、薄くしてもちゃんと発火します。 実は 公式 Docs も、description は「何をする＋いつ使うか」を簡潔に、しかも “Put the key use case first”（主要ユースケースを先頭に） が推奨なんですよね。公式が載せている例自体「〇〇する。 Use when 〜（こういうときに使う）」の 1〜2 文です。だから機能を網羅的に説明するより、「 どういうときに発火してほしいか 」——ユーザーが自然に打つトリガーキーワードを軸に短く書くのが、むしろ公式どおりなんです。（この辺んは使いながら調整です！） 実例。僕は自社サイト（SIOS Tech Lab）のブログ記事を Markdown で保存する CLI ツールを Skill 化しているんですが、これのトリガーは実質「 特定の URL 」なんですよね。 tech-lab.sios.jp の URL が流れてきて、「ブログ」「取得して」が添えられたら発火してほしい。それ以外は要らないんですよね。だから description はこう削れます。 # Before（公式の型には沿ってる。でも説明が多くて長め） description: | SIOS Tech Lab のブログ記事を Markdown に変換して保存する CLI ツール。 記事の URL を渡すと取得・整形して docs/data/blog/ に書き出す。 記事を手元に取り込みたいときや、バックアップを取りたいときに使う。 # After（トリガーだけ: 「いつ発火したいか」を書く） description: ブログをMD保存。tech-lab.sios.jp の URL +「ブログ」「取得して」で発火 長文が 1 行になりました。それでもちゃんと発火します。 慣れている Skill ほど description は薄くしていい というのが僕の結論です。用途を自分が把握しているなら、Claude にもキーワードだけ伝われば十分なんですよね。 外す・縮めるの使い分けと、削除前の「降格」 判断軸：「自動発火に価値があるか」の 1 問 ①外すか②縮めるかは、1 問で決まります。「 自動発火に価値があるか？ 」。 こんな Skill 判定 アクション 副作用あり（commit / deploy / 送信） 外す disable-model-invocation: true 名前を覚えていて /foo で呼んでる 外す 同上 特定の作業・ディレクトリでしか使わない 外す 同上・CLAUDE.mdに書くのもあり 「リサーチして」「スライド作って」で自動発火させたい 縮める description を薄く 引数を Claude に解釈させたい 縮める description を薄く 作ったばかりでまだ慣れていない そのまま デフォルトで様子見 たとえば「リサーチして」「スライド作って」みたいな自然な言葉で 自動発火してほしい Skill は、消さずに残して description だけ薄くしました。さっきのブログ取得ツールみたいに、URL がトリガーになるものも同じく薄くしたグループですね。 削除の前に「降格」で様子見する 最後に安全運用のコツを。「もう要らないかも」となっても、いきなり削除しないでください。 skillOverrides: "off" （settings.json）で 無効化して様子見 してから消すと事故りません。settings.json の編集だけで戻せるので、降格 → 戻す → 再降格がやりやすい。 skillOverrides は手書きしなくても、 /skills メニューで対象 Skill を選んで Space で状態をトグル → Enter で .claude/settings.local.json に保存できます（v2.1.129 以降）。 まとめ：赤文字は budget の SOS、答えは「削除」じゃなく「削減」 今回の流れを振り返ると、 ある日出た Skill listing will be truncated の正体は character budget （ コンテキスト × 1% / 個別 1,536 文字） 警告は 2 種類あり、 shortened （個別 cap 超過＝短縮）と truncated （予算超過＝まるごと消える）は意味が違う budget を上げるのは最終手段。先にやるべきは Skill 側の “削減” で、description を budget から 外す （ disable-model-invocation ）か、 縮める （薄い description）か 棚卸しはシンプルで、 /skills で一覧を出して、各 Skill を「自動発火に価値があるか？」で 外す / 縮める / そのまま に振り分ける。これを月 1 で回すだけ。慣れてきた Skill から順番に削っていけばいい。 以前は「発火しないなら Slash Commands に移す」しかありませんでしたが、今は frontmatter を 1 行いじるだけで済みます。Claude Code のアップデートで、character budget という構造的な問題にもこのやり方で対処できるようになりました。 赤文字が出たら、それは budget の SOS です。Skill を消すんじゃなく、description を削減する。答えは “削除” じゃなく “削減” でした。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Code:「Skill listing will be truncated」の正体と直し方 first appeared on SIOS Tech Lab .

Claude Codeのプロンプト履歴は”自分の思考ログ”になる ども！Claude Code と毎日仕事している龍ちゃんです。 最近ふと気づいたんですけど、僕、 人間と喋ってる時間より Claude Code と喋ってる時間のほうが長い んですよ。正直、AIを”一緒に働く相手”だと思っちゃってる節があるくらい（笑）。で、思ったんです。一日で一番言葉を打ち込んでる相手が Claude なら、 その入力には自分の思考がめちゃくちゃ溜まってるんじゃないか 、と。 そこで、 ~/.claude/history.jsonl に残ってる入力履歴を1ヶ月ぶん抜き出して、AIに渡してみたんです。 セッションは消えても 、自分が打ち込んだ入力のほうは消えてないんですよね。そしたら口癖も価値観も、自分でも気づいてなかったことまで次々言い当てられて、けっこうヒヤッと。今日はその中身と、やり方、それと”見えた自分”の活かし方まで書きます。 プロンプト履歴をAIに分析させたら口癖・働き方・価値観が丸裸に 頼み方は、凝ったプロンプトでもなんでもないです。抜き出した履歴をドサッと渡して、 「僕のプロファイリングをお願いします」 これだけ。ほんとにこれだけなんですけど、返ってきた結果は、爆笑とヒヤッが交互にくる感情のジェットコースターでしたね。 まず口癖が丸裸にされた AIが「あなた、こういう口癖ありますよ」って並べてきたのがこれ。 カテゴリ フレーズ 進捗確認 「どんなもん？」 承認 「いい感じ」「おっけ〜」 感謝 「あざまる〜」 依頼 「よろ〜」「頼みまーす」 関西弁 「ええやん」「せやな」「ほな」 照れ隠し 「ｗｗｗ」 いや、「どんなもん？」が最頻出って言われて、たしかに言ってるわ…ってなりました。関西弁も無意識すぎて、指摘されて初めて「あ、出てるんだ」って。しかも僕、 関西には縁もゆかりもない んですよ。なんで関西弁が出てるのか、自分でもよく分かってないっていう（笑）。 自分の口癖って、自分が一番わからないんだな と痛感しましたね。 仕事の進め方のクセまで見抜かれた 口癖だけじゃなくて、進め方のパターンも見抜かれてました。 発散→収束→資産化 ：まず調査して、壁打ちで方向を決めて、文章化して保存・コミットする 1セッション1テーマ ： /clear をこまめに叩いて、次に使うプロンプトを今のセッションで作る 裏で走らせる ：時間のかかる調査やタスクはバックグラウンドに投げて、自分は別の作業を進める 即断即決→壁打ち修正 ：直感で方向を出して、違和感があったらすぐ撤回する 「コミットしてプッシュして」が最頻出プロンプトの一つ、って言われたのは、なんか笑えなかったですね（笑）。でも、自分で「こういう進め方してます」って説明するより、入力履歴から逆算されたほうが、よっぽど解像度が高いんですよ。 価値観まで読み取られて、これが一番ヒヤッとした 今度はもっと踏み込んできて、繰り返し出てくる言い回しから「価値観」まで読み取られました。 Git管理できないものは信用しない ： Auto Memory を切ってるのもこれが理由。AIが暗黙的に覚えてるものより、自分で見えるドキュメントを信じるタイプ 「さぼる」はポジティブ ：手作業を減らすことを「さぼる」と呼んで、それを追求する文化が自分の中にあるらしい CLI > MCP ：「MCPは遅い・重い・トークン食う」を繰り返し言ってたらしく、まあ、思ってます 自分で言うより当てられたほうがドキッとするんですよね。誰かに言われたわけじゃなく、自分の入力データから出てきてる、っていうのが逃げ場がない。 極めつけ、AIを完全に”同僚”だと思ってた で、分析してて一番笑ったのがこれなんですけど。冒頭で「AIを一緒に働く相手だと思っちゃってる節がある」って書いたじゃないですか。あれ、 節どころか完全にそうでした 。 一番多かった文末、なんと「 〜かな？ 」が断トツ（数えたら160回超）。命令じゃなくて「これでいいかな？」って AIに相談・打診してる んですよ。「〜よね？」「〜ない？」みたいな同意確認も多くて、完全に隣の人に聞く感じ 承認も「おけ」「おｋ」「よいぞ〜」とバリエ豊富で、終始タメ口 極めつけ、 AIに「おはよ」って挨拶してた 回まであって。我ながら同僚すぎますね（笑） しかも砕け具合が増してるらしく、「ｗ」の数が 先月の10倍近く に。だいぶ気を許してますね うすうす気づいてはいたんですけど、ここまで数字で突きつけられると、もう言い逃れできないですね。完全に”隣の同僚”扱いでした。AIと働きすぎです（笑）。 おまけ：先月と比べたら、使い方が変わってた 前の月のぶんも抜いて比べてみたら、自分の 使い方の変化 まで見えました。これがおまけで面白かったところ。 セッションの引き継ぎを多用しはじめてた ：先月はほぼゼロだった引き継ぎ系のコマンドを、今月は30回以上叩いてた。1本のセッションに積まず、こまめに分けて渡す運用に、自分でも寄ってってたんですね（この”セッションを分ける”話は 別記事で書いてます ） /clear はずっと最頻出 ：先月も今月も、一番叩いてる短いプロンプトは /clear 。切る派、一貫してました プロンプトが長くなってた ：平均の文字数も、一番長いプロンプトの長さも、先月よりだいぶ伸びてた。雑な一言から、ちゃんと指示を書く方向へ 「違う」「戻して」も増加 ：直感で出して、違ったらすぐ撤回する壁打ちスタイルが濃くなってた 記録なんてつけてないのに、使い方の変化がデータから勝手に浮かび上がる。これ、上司でも他人でもなく、自分の入力データが相手なんで、忖度ゼロなんですよね。「ここ変わってきたな〜」とフラットに向き合える（笑）。というか向き合うしかないですね。 history.jsonlからプロンプトを抽出する方法（簡易スクリプト） 「で、それどうやって抜いたの？」ってとこですよね。 めちゃくちゃ簡単 です。 入力履歴は ~/.claude/history.jsonl に、1行1エントリの JSONL形式 で溜まってます。1行はこんな構造です。 フィールド 中身 display 入力したプロンプト本文（←今回の主役） timestamp 入力した時刻（Unixミリ秒） project どのプロジェクトで打ったか（パス） pastedContents 貼り付けた画像やテキストの中身（ {id, type, content} ） やることは、この display を期間で絞って、Markdown にして、AIに渡すだけ。 注意点が一つだけあって、 全部吸い出すとアホみたいな量になります 。僕が最初に1ヶ月ぶん全プロジェクトでやったら数千件・数百KBになって、コンテキストウィンドウがパンパンになりました。なので「直近◯日」「このプロジェクトだけ」で絞るのが現実的です。僕が見たのは、調査もブログも検証もコアに回してた、濃い時期の1ヶ月分です（プロジェクトはメインの1つに絞って）。 絞って抜くだけなら、こんな短いスクリプトで足ります。 extract_prompts.py として保存してください。Python環境がない方はBash＋jqで同様のことができるんで、やりたいことをClaude Codeに説明するかこのコードを渡せば解釈してくれますよ。 import json, sys from datetime import datetime, timedelta, timezone from pathlib import Path days = int(sys.argv[1]) if len(sys.argv) > 1 else 14 cutoff = (datetime.now(timezone.utc) - timedelta(days=days)).timestamp() * 1000 lines = [] for line in (Path.home() / ".claude" / "history.jsonl").read_text().splitlines(): if not line.strip(): continue e = json.loads(line) if e.get("timestamp", 0) < cutoff or not e.get("display", "").strip(): continue dt = datetime.fromtimestamp(e["timestamp"] / 1000, tz=timezone.utc) proj = e.get("project", "unknown").split("/")[-1] lines.append(f"- `{dt:%m/%d %H:%M}` [{proj}] {e['display'].strip()}") Path("prompts.md").write_text("\n".join(lines), encoding="utf-8") print(f"{len(lines)}件 抽出") あとは直近2週間ぶんを抜くなら、こう叩くだけ。 python extract_prompts.py 14 prompts.md が出力されるので、それを Claude に渡して「分析して」と言うだけです。 ちなみに今回見たのは history.jsonl ＝ 自分の入力だけ で、AIがどう返したかは入ってません。会話まるごと（AIの出力も含めて）は別の場所にセッション単位で残ってるんですが、そっちの分析は、どっちかというと真面目な用途向きなんですよね。「このセッション、なんでこんな変な結果になったんだ？」って失敗の切り分けとか。ただ、その手の “失敗を拾って仕組みに落とす”話は前に失敗をバグチケット化する記事 で1本書いてるので、そっちを読んでもらえれば。今回は自己分析なので入力だけで十分でした。複数セッションを横断してまとめて掘る、みたいな話はまた別記事で書く予定です。 history.jsonl には社内情報や認証情報が混ざってることがあります。 そもそも、そういうのは入力に打ち込まないのが大前提 なんですけどね！ そのうえで一番安全なのは、 外部に貼らずローカルの Claude Code にそのまま分析させること 。このやり方なら履歴がどこにも出ていきません。どうしても外部のAIや人に渡すなら、 grep -vi 'token\|secret\|password\|key' prompts.md で目立つ行は落とせます。ただしこれで消えるのは”その単語が書かれた行”だけで、 生でベタ貼りしたトークンの値や社内の固有名詞までは引っかからない ので、最後はざっと目視で確認してから渡してください。 分析結果をCLAUDE.mdに注入して”自分の粒度”で出力させる で、ここからが個人的に一番おいしいとこなんですけど。 この分析、見て「面白かった」で終わらせるのはもったいない んですよ。 考えてみると、出てきたのは「 自分が普段 Claude に何を・どんな粒度で・どんな価値観で求めてるか 」のかたまりなんですよね。だったらそれを、そのまま Claude 側の設定に 注入 してやればいい。 たとえば「CLI > MCP」って価値観が出たなら、CLAUDE.md に「MCPより既存のCLIツールを優先する」ってルールで書く。「Git管理できないものは信用しない」なら「判断の根拠はドキュメントに残す」とか。 分析で出てきた一言を、そのままルールの言葉に置き換えるだけ なんですよね。そうすると次からの Claude が、 最初から自分の求める粒度・スタイルで出力してくれる ようになる。毎回同じ注文を口頭で付け足さなくて済むんです。 自己分析って「鏡で自分を見る」ことだと思ってたんですけど、注入までやると、 鏡で見た自分を相棒の設定に還元するループ になるんですよね。見る → 効かせる、までやって初めて「やってよかった」になる。このへんの「分析結果をAIに注入する」考え方は、前に CLAUDE.mdへのドメイン知識の注入 とか 調査結果を構造化して注入する って記事でも書いてるので、合わせてどうぞ。 ちなみにこれ、個人なら自分の CLAUDE.md に書いて終わりなんですけど、 チームでやろうとすると話が一段ややこしくなります 。各自のエッセンスをどう共有資産に育てるか、って問題が出てくる。そのへんは 「Auto Memory をチームでは使わない理由」 のほうで別途書いてます（個人の学びをチームの資産に”昇格”させる話）。 おわりに プロンプト履歴って、結局「無意識の鏡」なんだなと思いました。意識して残したものじゃないのに、積み上がったら、自分でも気づいてなかった口癖や価値観まで全部映ってる。日々雑に打ち込んでるプロンプトも、立派な「自分の資産」だったわけです。 しかも見るだけじゃなく、そのエッセンスを CLAUDE.md に注入すれば、明日からの Claude が自分仕様になる。セッションは消えても、入力した思考は残る。それを次に活かせる。なんか、いいですよね。 ちなみにこれ、Claude Code を毎日触ってる人なら「コミットして」とか「これでいい？」系の確認は、たぶん誰でも上位に出ると思うんですよ。でも、そこから先の口癖とか価値観みたいな”その人らしさ”は、見事に人それぞれ。だからこそ、自分のを覗くと「うわ、自分こうなんや…」ってなるはずなんですよね。正直、みんなのもどんなもんか見てみたいくらい気になります。 ということで、ぜひやってみてほしいんです。凝ったことしなくていいので、さっきみたいに自分の history.jsonl を渡して「プロファイリングお願いします」ってざっくり頼むだけ。で、気に入った発見があったら、ついでに CLAUDE.md に一行足してみてください。あなたの「どんなもん？」が、見つかるかもしれないですよ。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Codeへの入力を分析させたら、口癖まで丸裸にされた first appeared on SIOS Tech Lab .

僕の手元では動くのに、同僚のところでは動かない ども！Claude Code と毎日仕事している龍ちゃんです。 ちょっと前に、同僚と2人で Claude Code を使い始めたときの話なんですけど。せっかくだからと、僕がガッツリ育ててきたリポジトリを、 .claude/ の中身ごとまるっと共有したんですよ。これで同僚も僕と同じように使えるはず、と思ってました。 ところが、です。 僕の手元ではちゃんと動くのに、同僚のところでは同じようにいかない 。一番わかりやすいのは、同じ指示を出してるのに結果が違うってやつ。僕がふわっとお願いするとデザインまで整った成果物が一発で出てくるのに、同僚のところだと崩れたものが出てきたり、コマンドがうまく動かなかったり。「いや、こっちだとちゃんと出るんだけど…？」って、あの不毛なやつです。 原因をたどっていって、行き着いたのは身も蓋もない事実でした。 うまくいってたのは、共有リポジトリのおかげじゃなくて、僕のPCの中だけに溜まってた”何か”のおかげだった 。リポジトリには乗ってない、僕の手元だけが知ってる前提が、こっそり下支えしてたんですね。しかもその正体を知ったとき、便利を通り越して、正直ちょっとゾッとしました。 今日はその”何か”の正体と、チームで Claude Code を使うときどう構えるか、って話です。 犯人は「勝手に賢くなる」Auto Memory だった その”何か”の正体が、 Auto Memory です。Claude Code が会話の中から「これ覚えとくと良さそう」って学びを勝手に拾って記録してくれる機能ですね（ v2.1.32 で登場 、 v2.1.59 で /memory から管理できる ようになりました）。 これ、オンにしてた頃にちょっとゾッとしたことがあって。作業の途中で Claude がしれっと「 前回これで失敗したので、回避策としてこっちを確認しますね 」って言い出したんですよ。いやいや、その失敗、このセッションでは一度も話してないんですけど、と。Auto Memory がせっせと記録してたわけです。 便利なんですよ、ほんとに。こっちの好みも、よくやる失敗も、勝手に覚えてくれる。 雑なプロンプトでもいい感じに解釈してくれる ようになる。…でもこれ、よく考えると「僕の入力だから通じてる」だけなんですよね。同僚が同じ雑な指示を出しても、向こうの Claude はそんな学習してないから、通じない。さっきの「同僚で動かない」の正体がこれです。 僕の Claude だけ、見えないゲタを履いてた わけ。 しかも保存先がクセモノで、公式にもこう書いてあります。 Auto memory is machine-local. … Files are not shared across machines or cloud environments. （Auto memory はマシンローカルです。ファイルはマシン間・クラウド環境間で共有されません） — Claude Code 公式ドキュメント この マシンローカル（machine-local） ってのがミソで、保存先は ~/.claude/projects/<project>/memory/ 、つまり僕のホームディレクトリの中。リポジトリの外で、git にも乗らない。 僕のPC1台の中に、Claude の賢さがこっそり溜まっていく んです。 龍 もし公式が対応してるぞ！って情報があったら教えてください。すぐブログを公開停止にするんでｗ でも、チーム単位でメモリーをGit管理できるようにするって結構有用だと思うんですよね～ ただ差分が地獄になりそうですけど… Docker で環境を揃えたのに、AIの賢さだけPCに残るのは違う で、ここが僕的に一番引っかかるところで。 僕、開発環境は基本ぜんぶ Docker 化してるんですよ。「Docker さえ入ってれば、どのPCでも同じ環境が立ち上がる」状態にしてある（Docker じゃなくてもいいんですけど、要は”誰のPCでも同じになるように揃える”あれです）。PC を乗り換えても、認証を通せばすぐ元通り。「俺の環境だと動くんだけど」っていう、あの不毛なやつを消したくて、けっこうな手間をかけてきました。 その努力をしておいて、 AIの賢さだけが僕のPCのローカルに溜まってたら、本末転倒 じゃないですか。環境は再現できるのに、Claude の振る舞いだけは僕のPCでしか再現しない。せっかく追い出したPC依存を、Auto Memory が裏口からこっそり呼び戻してるのと同じなんですよね。 そもそも僕、 git で管理できない設定やメモリって、あんまり信用してない んですよ。だから Auto Memory は、チーム運用の前提だと意図的に切ってます。リポジトリの設定に CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 と書いて、ガッツリ無効化。「Docker さえあれば同じ」を、Claude の賢さのところまで広げたいんです。 「勝手に学ぶ」と、失敗を育てる気がなくなる PC依存の話だけじゃないんですよ。Auto Memory って、失敗も勝手に吸収してくれるんですよね。一見ありがたい。でも勝手に吸収されると、 「この失敗、どう仕組みに落とそうか」って考えなくなる んですよ。本来なら、失敗を拾って CLAUDE.md やスキルに反映して、環境ごと育てていく——その一番おいしい作業を、Auto Memory がサボらせちゃう。同じ目的に「自動で覚える」と「自分で書く」の2つの道があると、つい自動のほうに任せて、手で書くほうが形骸化するんですよね。ぶっちゃけ僕も、Auto Memory を切って初めて、CLAUDE.md をちゃんと書くようになりました。 それに、メモを書いてるのが Claude 自身なので、 何をどう記録するかは人によってバラバラ 。Aさんのメモリはよく育ってて、Bさんはこれから、なんてことになる。「教訓」と言いつつ品質が揃わない。チームの共有資産としては、ちょっと危なっかしいんですよね。 実は公式も、Auto Memory は「Claude が自分で書くもの」、CLAUDE.md は「人間が書いてチームで共有するもの」と、はっきり役割を分けてます。 Auto Memory CLAUDE.md 書くのは誰 Claude あなた（人間） 中身 学びとパターン 指示とルール 有効範囲 そのPCの中だけ プロジェクト / チーム / 組織 （ Claude Code 公式ドキュメント の対比表より） 裏を返すと、 チームの教訓は CLAUDE.md に書け 、ってことなんですよ。Auto Memory に任せきると、この「CLAUDE.md を育てる」という観点がスポッと抜け落ちる。新しく入った人の Claude もゼロからスタートになっちゃうしね（ちなみに Anthropic 社内でも、新メンバーが CLAUDE.md を読んでコードベースを理解する って使い方をしてるらしいです）。 教訓は「共有できる場所」に昇格させる じゃあどうするか。やることはシンプルで、Auto Memory の逆をやればいい。「Claude が・自分のPCに・勝手に書く」んじゃなくて、 人間が・共有リポジトリに・意図して書く 。この「個人のPCに溜まる学びを、チームで共有できる場所に移しかえる」ことを、僕は “昇格” って呼んでます。で、Claude Code には、その昇格先になる”共有できる器”がちゃんと用意されてるんですよ。 CLAUDE.md … プロジェクトのルールや方針を書く場所。公式も、git に入れてチームで共有しよう、って言ってます（訳が正しければ、ですけどｗ） .claude/ のスキル・コマンド … 繰り返す手順を入れておく。 .claude/ ごと git に乗せれば、チーム全員が同じものを使えます サブエージェント … 特定の役割を持たせた専門の Claude ですね。これも .claude/agents/ で共有できます で、おもしろいのが、 この”昇格”の手順、公式には載ってない んですよ。Auto Memory と CLAUDE.md を別物として並べてはくれるけど、つなぎ方は書いてない。 だから自分たちで設計するしかない。ここが「自前で管理する」ことの存在理由 です。 僕が意識してるのはシンプルで、 人間が「これは残す価値があるか」を判断して （ここを Claude任せにしない）、 種類で分けて置く 。ルールなら CLAUDE.md、手順ならスキル、役割ならサブエージェント。この振り分けが雑だと、また「僕の手元では動くのに」のループに逆戻りです。 実際、このブログを書いてるリポジトリ自体が、昇格の積み重ねでできてます。 スライドで何度も再発明してた CSS のレイアウト手法 → 教訓化して スキルのリファレンスに昇格 。以来どのプロジェクトでも一発 アウトライン改訂で Claude が履歴を本文に書き込む失敗 → 「最新版だけ残す」 ルールを CLAUDE.md に昇格 。誰の環境でも書き方が揃う 「勝手に学ぶ」んじゃなく「人間が分けて積んだ」結果だから、別のPCでも、新しい人が入っても同じように動く。冒頭で困ってたやつの、ちょうど逆ですね。 じゃあ、どうやって昇格させるの？ 「言いたいことは分かったけど、実際どうやって失敗を拾って昇格させるの？」ってところですよね。 ここは前に1本まるごと記事 にしてるので、そっちも読んでみてください。 2026-03-16 Claude Codeの失敗をバグチケット化して潰す方法 やってることはシンプルで、失敗が起きた瞬間に「教訓ファイル」として書き出して、CLAUDE.md やスキルに反映したら消す。 「ファイルがある＝まだ直してない」 っていう、バグチケットみたいな扱いにしてます。永続的に積み上げるんじゃなくて、消化したら消す。 ミソは分担なんですよね。 「こうしてほしかったのに、こうなった」っていう”意図”だけ人間が書いて、原因の分析は Claude に任せる 。さっき書いた「判断は人間がやる」が、ここで具体的なプロンプトに落ちてる感じです。実際に僕が投げてるプロンプトもそのまま載せてるので、コピペで試せます。単純に失敗の記録だけでなく、チーム内でのClaude Codeとの付き合い方みたいなところのディスカッションもできるんで結構よいと思いますね。 この記事が「 なぜ 昇格させるのか（チームと再現性のため）」だとしたら、あっちは「 どう 昇格させるか」。あっちと合わせて読むと、全部つながるはずです。 おわりに 最後に。ぶっちゃけ、Auto Memory 自体はダメな機能じゃないです。1人で使う分には勝手に賢くなって普通に便利。否定したいわけじゃ全然ない。ぶっちゃけ、チーム全員が Claude Code 熟練者で、各自そのへんを分かった上で使うなら、切らなくてもいいと思います。 でも、これから広めていく段階——みんながまだ手探りのときに、Auto Memory で「なんか動く」状態を作っちゃうと、なんで動いてるのか誰も分からなくなる。だから僕は、今の段階では切る。そして教訓は、勝手に溜めるんじゃなく、ちゃんと分けて、共有できる場所に育てる。 最初の一歩はかんたんです。まず CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 で切る。そのうえで、次に「お、これ覚えとくと良さそう」と思った学びを、1個でいいから自分の手で CLAUDE.md に書いてみる。それだけで「勝手に溜める」から「分けて育てる」に、頭が切り替わると思います。（割と強火な思想なんで失敗からの共有だと優しい目でお願いしますｗ） Auto Memory は” 個人の相棒 “、CLAUDE.md やスキルは” チームの資産 “。役割が違うんですよね。「Docker さえあれば誰でも同じ」を、AIの賢さのところまで広げる。たぶんそれだけで、隣の人の Claude も、ちゃんと同じように動いてくれるはずです。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Code Auto Memory をチームでは使わない理由 first appeared on SIOS Tech Lab .

1つのセッションに何でも混ぜがち、な話 ども！Claude Code と毎日仕事している龍ちゃんです。 コード書いてる途中に「そういえばあの調査どうなったっけ」ってなって、同じセッションで聞いちゃう。気づいたら1本のセッションに、関係ない話が何本も混ざってる。正直、僕も今でもやりがちなんですよね〜。 これ、「詰め込みすぎると回答の質が落ちる」からやめた方がいいんですよ。容量がもったいないとかじゃなくて、”質”のために分けてる。本筋に関係ない文脈をメインのセッションに混ぜない、っていうのが基本の考え方です。 今回は /btw ・subagent・別セッションを「どの粒度で切り出すか」で使い分ける話をします。分けたり、切ったり、ちょい聞きで逃がしたり、っていう”構え”の話ですね。コマンドの使い方は後半に出てくるんですが、先に「なぜ分けるのか」をおさえておくと、使い分けの判断がはっきりするんですよね。 じゃあ、なんで分けたほうがいいのか。まず前提の話からなんですが、コンテキストウィンドウが1Mになってから、僕、 /compact をほぼ叩かなくなったんですよね。昔は膨らんでくると「そろそろ限界かな」って畳んで、また続けて…ってやってたんですが、1Mってちょっとやそっとじゃ全然埋まらないんですよ。容量を気にする時代、もう終わったかなって思ってます。 ……で、ここなんですよ。区切られなくなったってことは、ほっとくと1本のセッションが延々と膨らみ続けるってことでもあるんですよね。で、体感的に「入れすぎると質が落ちる」っていうのがあって。情報を絞ると欲しい答えが爆速で帰ってきたりもするんですよ、逆に。 セッションに積むほど ▶▶▶ 容量 ████████████████████ まだ全然いける（1M） 品質 ███████▓▓▒▒░░░░░░░░░░ ぼやけてくる ※あくまで体感のイメージ図です（測ったデータじゃないです）。ただ、コンテキストを積むほど精度や再現性が落ちていく現象自体は、公式ドキュメントでも “context rot” として説明されています 。「容量はまだあるのに質は落ちる」って、僕の体感だけの話じゃないっぽいんですよね。（割と有名な話な気もしますね） じゃあ「盛りすぎたな」ってどう気づくかなんですけど、会話が変なことを言い出すんですよ。もう一個は、変なものを作ってくる。この2つが来たら「あ、もう詰まってるな」っていうサインだと思ってます。 どう分けるか：「切り出す粒度」でコマンドと指示を変える で、「分ける」と一口に言っても、粒度がいくつかあるんですよね。僕の中では、小さい順にこう並んでます。 /btw （一問）＜ subagent（一作業）＜ 別セッション（関連作業まるごと） 雰囲気で言うと、こんな差なんですよね。 /btw ：「ちょっと聞かせて〜。答えてくれたら忘れてね〜」（聞いたら忘れる） subagent ：「これ読んで、これやっといて。終わったら報告ちょうだい！」（結果だけ返す） セッション（普通のチャット） ：「これ見てこれやって。会話は覚えといてね。…長くなったら、なんとなく忘れちゃうかも〜」（覚えてる、けど長いと薄れる） この地図を持っておくと判断が楽になります。1つずついきます。 /btw ：逸れた”一問”を、残さず聞く 一番小さい粒度。 /btw <question> は、 会話に残らない”ちょい聞き” ができる 組み込みコマンド です。いまの会話の文脈は全部見えてるんだけど、その質問と答えはメインの履歴に残らない。聞きたいことだけ聞いて、本筋はそのまま、というわけですね。 僕がよく使うのは、こんな質問です。 セッション中に出てきた 知らない単語 の意味を聞く 「 今どういう状態だっけ 」っていう現状確認・理解のための質問 どっちも共通してるのは、「その場で分かりたいだけで、後で要らない」ってこと。普通に聞いちゃうと、本筋の会話に確認のやり取りが挟まって文脈が薄まる。 /btw ならそれを汚さずに済む。 By Tha Wayって直感的でいいコマンドですね!(^^)! subagent：単発の”一作業”を投げる /btw の一個上の粒度が subagent です。なんで /btw の隣に置くかというと、この2つ、ちょうど対になってるんですよ。 /btw はツールなし・文脈フル、subagent はツールあり・文脈は空っぽ。この「文脈が空っぽ」ってのは、いまのメインの会話を何にも引き継がないで、まっさらな状態で立ち上がるってことなんですよね。で、ここがミソなんですけど、空っぽだからこそ、こっちが渡したい文脈だけを選んで持たせられる。「これとこれだけ読んで、これやっといて」って、必要なぶんだけ渡すイメージですね。つまり「この会話で既に分かってることを、汚さず聞く」のが /btw 、「渡したいぶんだけ持たせて、新しいことを調べに行かせる」のが subagent ですね。僕はこの2つを「逆向きの兄弟」みたいに捉えてて、これ覚えとくと迷わなくなると思います。 考え方としては「別セッションに分ける」のともかなり近い。文脈を渡して別の場所で作業させる、という点では同じなんですよね。違いは粒度で、subagent は一つの作業を投げて、結果を受け取るイメージです。だから粒度の地図だと、ちょうど /btw （一問）と別セッション（まるごと）の真ん中に座る、という感じですね。 あと品質の話もあって。限定された文脈で作られた成果物ってクリーンなんですよ。余分な文脈が入ってないぶん、余計な影響を受けずに仕上がってくる感覚です。 別セッション：関連作業を”まるごと”引越す そして一番大きい粒度が、別セッションです。subagent が「点」で一作業を投げるのだとしたら、別セッションは「面」。 関連する一連の作業をぜんぶそっちに引越して、自分が腰を据えてやる 感じですね。 僕が別セッションを立てるのは、だいたいこんなときです。 応答が遅くなってきた ：長くなりすぎたセッションは返信に時間がかかるので、そろそろ引越すか、と 忘れないように切り出す ：作業中に割り込んできた別件を、本筋に混ぜず別セッションに逃がす 先にこれだけ進めたい ：ここまでの内容を別の作業として切り出して、優先で片付けたいとき で、別セッションに引越すときに大事なのが、丸投げじゃなく”お引越しプロンプト”を持たせてあげることなんですよ。引越し先のセッションは、こっちの文脈をなんにも知らない。だから「いま何をやってて、次に何をしてほしいか」をちゃんと書いて渡す。「何を引き継ぐか」を決める作業こそ、”分ける”の本体なのかなって思ってます。 ここで /clear を使うのがポイントで。前の文脈を持ったまま引き継ぎ文を書けるので、ちゃんと残せてるか確認して、納得いくまで練り直せるんですよ。 /compact のほうは会話履歴を要約に置き換える動きなので、畳んだ後だと元の詳細はもう手元になくて、そこの確認がしづらいんですよね。 僕はこのお引越しプロンプトを、 考え方で2種類 用意してます。 継続用（next） ： 同じトピックをそのまま続けるための引き継ぎ。作業の温度を冷まさないように、途中経過とか決まったこと、残タスクまで、なるべくそのまま持っていく感じ。 切替え用（new） ： 別のタスクに頭を切り替えるための引き継ぎ。逆に、ここまでの細かい経緯はいったん捨てて、次にやることに本当に要るものだけ選び直して渡す。（途中で本筋と同時並行でできるけどコンテキストを分けたいときにも！） 「このまま続きをやるのか」「別件に移るのか」で、”何を残して何を捨てるか”がちょうど逆になるんですよね。だから最初から2つに分けてます。 〔コラム〕お引越しの荷物は `/copy` で運ぶ お引越しプロンプトができたら、あとは新しいセッションに持っていくだけ。ここで地味に効くのが `/copy` です。直前の応答をそのままコピーして、新しいセッションに貼る。それだけ。以前はこういうの xclip を手で叩いてやってたんですが、もうこれで済みます。渡したい粒度に合わせて、応答の一部だけ選んだり、ファイルに書き出したりもできます。 compactでよくない？確かにいいけど切るほうが個人的に良い ここまで「分ける」話をしてきましたが、1本のセッションが重くなってきたとき、やり方は2つ。 切って新しく始める → /clear 畳んで同じセッションで続ける → /compact 「重くなってきたら /compact で畳めばいいじゃん」って思う人、多いと思います。でも僕の基本方針は、切る派です。重くなる前に /clear をこまめに連発して、どんどん新しいセッションに移る。 /compact が必要になるまで粘らない。 なんでかというと、そもそも /compact してまで1本で続けたい「超絶長いタスク」って、そんなにあります？ってことなんですよね。タスクを「終わる分量」で切っていれば（この話も 別記事で git log を例に書いてます ）、1個終わったら /clear して次にいけばいい。延命する理由がないんです。長く粘ったセッションほど文脈が盛られてさっきのサインが出てくる、というのとも地続きで、僕の中では「重くなったら畳む」より「終わったら切る」が先に来ます。 とはいえ /compact を全否定したいわけじゃなくて。どうしても途中で切れない長いタスクには、ちゃんと効きます。そのときは /compact のうしろに「何を重点的に残すか」を書けば、その方向で要約して畳んでくれる。僕の出番は正直少ないですが、”切れない長丁場”のときの逃げ道として知っておくと安心です。 おわりに 結局「セッションを分ける」って、新しい道具を覚える話じゃなくて、積み方の癖の話なんですよね。1M入るようになっても、いや、入るようになったからこそ、「これ、メインに残す意味ある？」って一回立ち止まる。残さなくていいものは残さない。終わったタスクは、粘らず切る。たったこれだけで、返ってくる答えの精度は地味に変わる気がします。 「あ、これメインに残さなくていいやつだ」と思った質問から /btw で逃がしてみてください。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Codeのセッションを分ける運用術：3つの粒度で使い分ける first appeared on SIOS Tech Lab .

2026年6月3日（水）～6月4日（木）の2日間、 九州教育現場支援EXPO に出展いたします。会場は、マリンメッセ福岡です。 サイオステクノロジーはクラウドとOSS、認証技術のスペシャリスト集団です。SaaSサービスや自動化技術で業務効率化を進め、教育機関のDXを支援します。ブースでは、下記サービスをご紹介しております。 文教向け「証明書自動更新ソリューション」 証明書自動更新ソリューションは、SSLサーバー証明書を一元管理し自動更新します。最長47日化に伴う大学の更新負荷を軽減し、運用コスト削減とセキュリティ強化に貢献します。 文教向け「SIOS Shibboleth IdPサービス」 認証ソリューション「Shibobleth IdP」をコンテナ化し、お客様Azure基盤上にスムーズに導入できる環境を提供します。導入の初期コストを抑えながら、迅速かつ柔軟な運用を実現します。 クラウド型ワークフローシステム「グルージェントフロー」 Microsoft365、Google Workspaceと連携するクラウド型ワークフローシステム。直感的な操作性を実現し高度な経路設計もサポート。学内文書、学外文書、稟議書の電子化を実現します。     お近くにお越しの際は、ぜひご来場ください。 The post 6/3(水)～6/4(木) 九州教育現場支援EXPOに出展します first appeared on SIOS Tech Lab .

2026年6月10日（水）～6月12日（金）の3日間、 AI NATIVE EXPO2026 に出展いたします。会場は、幕張メッセです。 サイオステクノロジーのブースでは、下記サービスをご紹介しております。 SCANOSS ― 生成AIコードに潜むOSSリスクを可視化 SCANOSSは、生成AIが出力したコードを含むソースコードを解析し、内部に含まれるOSSコンポーネントやライセンス情報を可視化するコード解析ツールです。ブラックボックス化しやすい生成AIコードの中身を明らかにし、ライセンス違反や著作権リスクの早期発見を支援します。独自の解析技術により、利用OSSの特定や重複検出を高精度に実行。開発現場におけるOSS利用状況を正確に把握し、リスク管理とコンプライアンス対応を支える基盤を提供します。生成AI時代に求められるOSSリスク可視化を実現します。 お近くにお越しの際は、ぜひお立ち寄りください。 The post 6/10(水)～6/12(金) AI NATIVE EXPO2026に出展します first appeared on SIOS Tech Lab .

「先週なにやってたっけ」を、git log に書いてある状態にしておく ども！Claude Code と毎日仕事している龍ちゃんです。 月曜にやったこと、金曜には忘れてるんですよね。タスクが増えてくると「追い切れる気がしない」になって、ちゃんとやろうと思っても結局やらない、みたいな。 そういう人に向けた話なんですが、前提を先に言っておきますね。2つあって。 全業務（ブログも調査もツール開発もセミナー資料も）を 1つのリポジトリ に突っ込んでいる それは 個人 の進捗管理リポジトリで、作業者は自分1人 この2つが揃ってるから、 git log が自分の活動ログになるんですよね。土台の「全業務を1つのリポジトリに集約してる」話自体は「 Claude Codeで全業務を1リポジトリに一元管理する作業基盤の作り方 」で書いていて、そこで「git の履歴がそのままタスクの棚卸しになる」と予告してたんですが、今日はその中身の話です。 2026-06-02 Claude Codeで全業務を1リポジトリに一元管理する作業基盤の作り方 やってることは特別なことは何もなくて。Claude Code に書かせたコミットメッセージと時刻を git log でちらっと眺めるだけ。マジで小さい Tips なんですが、地味に効いてるのでおすそわけします。 この記事の全体像は、こんな感じです。 なぜコミットログが「作業ログ」になるのか じゃあなんで、ただの git log が作業ログとして読めるのか。理由は2つです。 1つめは、 コミットメッセージを Claude Code に書かせてる こと。差分を読んで「何を・なぜ変えたか」を要約してくれるので、書き方が安定するんですよね。自分で手打ちしてると、つい fix とか wip みたいな雑なログになりがちなんですが（笑）、Claude に書かせると一文できちんと残る。だから後から読み返しても意味がわかります。「”wip” じゃ後から誰も分からないけど、AIに書かせたら実際に役立つ履歴になった」って言ってる人もいて（ freek.dev ）、これめちゃくちゃ分かるんですよね。 もう1つが、これが今日のポイントになるんですが。理想を言えば、 タスクを「終わる分量」で切る ことなんですよね。1個終わるごとにコミットが1つ落ちる＝コミットが「完了の単位」になる。結果、 git log が「終わらせたことが時系列に並んだ列」になる。いわゆる atomic commits ってやつですね。「コミット履歴はコードがどうしてこうなったかを語る”物語”だ」って言ってる人もいて（ Telling stories through your commits ）、まさにそれを作業ログとして読んでる感覚です。 でも現実は、当日朝にいきなり降ってくるタスクもあるし、月末締めのやつと今週中のやつが混在してたりして。粒度をそろえて設計する、できてるか？というと、まあ僕もできてないです（笑）。 そこで Claude Code にコミットを書かせると、差分を読んでファイル単位で適切な粒度に分けてくれるんですよね。僕がよくやるのは、ダーッと一日走り切って、コミットの分割は後から AI に丸投げするやつ。設計しきれてなくても、それで足りてます。 だから個人で運用する分には、「自分しか見ない＝コミット粒度のルールが本来ない世界」でも、 git log がそのまま活動ログになるんですよね。ちなみにこれ、リポジトリを分けてたら履歴も割れて1本で見渡せないんですが、全部1リポジトリだから成立してます。 長めのタスクのときは、いったん途中でコミットを切っておいて、翌日 git log で「どこまでやってたか」を確認してから戻る、という使い方もしてます。 実際、時刻付きで眺めるとこんな感じで並びます。 $ git log --pretty=format:"%cd %s" --date=format:"%m/%d %H:%M" 05/31 23:09 docs(article): 連載のブログ記事と計画を追加 05/31 23:09 docs(research): /copyの調査結果を追加 05/31 16:44 docs(slides): 月次LTのスライドを改稿 05/29 14:32 feat(tool): サムネ生成のオプションを追加 05/29 10:10 docs(seminar): OSCの企画ドキュメントを追加 「いつ・どの領域で・何を終わらせたか」が、ただの履歴なのにちゃんと読める。 何に効くか いちばん多いのはタスクの復帰ですね。中断してたタスクに戻ってきたとき、直前のコミットを見れば「あ、ここまでやって、次これやろうとしてたわ」が一発で思い出せる。長いチャット履歴を遡らなくていいんですよね。 週次・月次の振り返りにも効きます。 git log --since="1 week ago" --author="$(git config user.name)" （月次なら --since="1 month ago" ）みたいに期間と自分を絞れば、「この期間やったこと」がそのままリストで出てくる。週報や月次レポートを書くときはもちろん、出した報告を「先月ほんとにこれやってたっけ」と裏取り確認するときにも、ゼロから思い出す作業がなくなって、素材がほぼそこにある状態になります。 あとは地味に、自分の稼働の把握。どの領域にどれだけコミットしてたかを見てると、実際に手を動かして終わらせた量がうっすら見えてくるんですよね。終わる分量で切ってるぶん、コミットの分布が「実際に終わらせた仕事」にわりと近いです。正確な稼働率みたいな数字じゃないですけど、「今週は調査に寄ってたな」「ツール開発、全然進んでないな」くらいの肌感は掴めます。しかもこれ、上司に報告するためじゃなくて自分のためなので、相手が自分のデータな分、忖度ゼロで「先週サボってたな〜」と向き合えるのがいいところです（笑）。 もう1つ意識してるのが、「git に乗らない仕事は、乗せにいく」というやつです。会議とかチャットって、ふつうはリポジトリに残らないじゃないですか。なので僕は、Google Meet の文字起こしはファイルを作ってリポジトリにコミットしてますし、Slack でのレビューも「何を投げて、それに対してどう返ってきたか」をファイルとして保存してます。 もちろん社外秘や他メンバーの発言が混ざるものは入れない、と人間が判断したうえで、ですが 手作業にはなるんですが、「なぜこうなったか」の意思決定の過程って、後から見返したときに価値があるので。作業の進捗はひとつのリポジトリで一元管理しようっていう意識です。まあ、乗せ忘れたものは映らないんですけどね（笑）。 Claude Code のログ分析でも、同じことはできるけど 正直に言うと、同じような振り返りは Claude Code 側のデータでもできます。 claude --resume を叩けば過去セッションの一覧が出て、各セッションのサマリーや最終更新時刻、git ブランチが並ぶので、「このへんで何やってたか」をたどれます。もっとガッツリやるなら、会話ログ（セッションの全文）を分析にかける手もあります。 でも、 見る量が多いんですよね。 会話ログは1セッションで数百行いくし、セッション一覧のサマリーも粒度がまちまちです（セッションに自動でタイトルが付くのは Plan を承認したときなどで、名前を付けてないセッションは最初のプロンプトがそのまま表示されたりする）。ぱっと「何やってたっけ」を解消したいだけなら、ちょっと情報が多い。 その点 git log は「メッセージ＋時刻」だけ。見る情報が少ないぶん、さっと振り返るには圧倒的に軽いんです。正直、git log が楽すぎてセッション一覧をわざわざ開く気にならないんですよね（笑）。 逆に、Claude Code のログ分析が向いてるのは、セッションをまたいで「どういう経緯でこの判断に至ったか」とか「自分のクセ・口癖」みたいな、もっと踏み込んだ詳細分析のほうですね。軽く棚卸ししたいだけなら git log、腰を据えて深掘りしたいなら会話ログ、という住み分けです。そっちのガッツリ系をやりたくなったら、また別記事で紹介しますね。 おわりに タスク管理ツールを新しく増やさなくても、コミットメッセージを Claude Code に書かせてるなら、 git log はもう作業ログとして読めます。まずは自分の git log を時刻付きで眺めてみるところから。「あ、先週これやってたわ」が見えてくると、地味に面白いですよ。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post git logが作業ログになる：Claude Codeにコミットを書かせるだけ first appeared on SIOS Tech Lab .

仕事の素材が散らばっていると、AIは手伝いきれない ども！Claude Code と毎日仕事している龍ちゃんです。 調査メモはNotion、コードはGit、ブログの下書きはGoogle Docs、スライドはまた別のツール……仕事の素材って、気づくとあちこちに散らばってませんか。 地味につらいのが「 AIに手伝ってもらいにくい 」こと。せっかく Claude Code を使っていても、調査メモが別の場所にあると「先月の調査をもとに、このコードのことを記事にして」が一発で通らない。毎回こっちが文脈を運ぶ羽目になります。 で、たどり着いた答えはすごくシンプルで。 日常のどんなタスクも、1つのリポジトリの中で進める 。調査も検証も実装もブログも、全部そこでやる。それだけです。 これをやると、いいことが2つあって。1つは、Claude Code が全部読んで横断して手伝ってくれること。もう1つが やった作業が消えずに積み上がる ことなんですよね。ここで言う”積み上がる”は、一度やった調査や検証が、後の別のタスクから参照されて使い回せる状態のことです。バラバラのツールでやると、終わったタスクはそのまま埋もれて消える（うっすらとした記憶で探すのも大変）。でもリポジトリの中で進めれば、調査も検証も全部残って、次の仕事の土台になる。点だった作業が、線でつながっていく感覚です。 この記事では、その「全部1リポジトリ」をどう組んで、どういう連鎖が起きて、どこから始めればいいかを順に話します。 全業務を1つのリポジトリに集約している まず、どんなエンジニアにも共通する話をします。コードを書く人なら、調査も検証も実装も同じリポジトリに置くだけで、「なんでこの設計にしたんだっけ」と悩む時間が減ります。コードの隣に検証メモが残っているし、「あの調査どこだっけ」と探し回らなくていい。仕事の種類は関係ないんですよね。 僕の場合は、さらに発信活動も業務の一部に入っているので、ブログやセミナーも同じ場所に置いています。会社としてテックブログとYouTubeチャンネルを運営していて、情報発信も仕事のうちになっているんですよね。だから開発・調査・発信が全部同じ業務として同じ場所にある、というのが実情です。 ディレクトリがそのまま業務の地図になっていて、こんな感じです。 リポジトリ/ ├── docs/ │ ├── research/ # 調査・リサーチ │ ├── experiment/ # 検証・実験 │ ├── article/ # ブログ記事の下書き │ ├── seminar/ # セミナー企画・登壇資料 │ └── data/ # 業務まわりのデータ置き場 │ ├── blog/ # 公開ブログのスクレイピング │ ├── pv/ # 月次PVデータ │ ├── x-post/ # X（旧Twitter）投稿 │ ├── youtube/ # YouTube用の原稿 │ └── … # チラシ・登壇資料なども └── application/ # 開発・ツール実装 git に乗らない仕事は、乗せにいく コードやドキュメントみたいに自然と git に残るものだけじゃなくて、放っておくと残らない仕事もあえてここに入れています。たとえば会議（Google Meet）の文字起こしや、Slack でもらったレビューのやり取り。ふつうはリポジトリの外で流れて消えていくものなんですが、ファイルにして置いておくと「なんでこう決めたんだっけ」の経緯まで同じ場所にそろうんですよね。手作業にはなるんですけど、後からじわじわ効いてきます。 会議録や Slack のやり取りには、社外秘や他のメンバーの発言（＝第三者の個人情報）が混ざりがちです。リポジトリを公開・共有・画面共有する場面で一緒に漏れる導線になるので、そういうものは別管理にするか .gitignore に入れる、保存自体も所属組織のポリシーに沿う、を前提にしてください。 ここで大事にしているのは、 何をリポジトリに入れるか（＝AIに読ませるか）は人間が判断している ということです。デリケートな情報は、そもそもリポジトリに置かない＝AIにも渡さない。AIに自動で何でも食わせるのではなく、「これは入れてよい素材か」を人の目で一段かませる。僕も「出していい素材」と「社外秘」は置き場を分けていて、後者はそもそもこの仕組みに乗せません。 整理されていること自体が目的じゃないんですよね。「ここに全部ある」という状態が、後の仕事の進めやすさを変えます。次のセクションで具体的に話しますね。 点と点が、線でつながった 「全部1つのリポジトリに入れた」結果、一番大きく変わったのは「知識の使われ方」ですね。 以前は、調査した内容は調査ノートの中で完結していました。記事を書くときは記事フォルダだけ見て、コードを書くときはコードだけ触って、という感じで。それぞれの仕事は「点」として存在していたんですよね。 それが1つのリポジトリに集まると、調査→検証→実装→発信という流れが、ファイルのパスをたどるだけで全部追えるようになりました。 docs/research/ での調査が起点になって、そこから docs/experiment/ での検証に進み、検証結果は2方向に分岐します。エンジニアとしての成果は application/ の実装へ、発信としての成果は docs/article/ のブログ記事やセミナー資料へ。さらにブログが公開されると、PV分析の結果を見て次の調査テーマが決まっていく。こうして、バラバラだった点が線でつながって、ぐるっと循環するようになります。 この「つながり」こそが、僕がやりたかったことの正体だと思っているんです。点のままだと、作業が終わった瞬間に埋もれていく。でも線でつながっていれば、どこかの作業が後の作業の土台になる。調査メモが記事を変え、記事のPVが次の調査を決め、検証の経緯が実装の判断根拠になる。やった仕事が消えずに積み上がっていく、という感覚です。 線でつながっている実例 コードの前に、検証の計画をドキュメントで残す 検証や実験をするとき、僕はいきなりコードから書き始めないんですよね。先に「何を確かめたいのか」「どういう手順でやるのか」「どんな仮説を置くのか」をドキュメントに書いて、整理してから実装に入ります。いわゆるドキュメント駆動ですね。 たとえば最近やった MCP サーバーの検証だと、「返ってくるデータ量やツール定義の書き方が、LLM のトークン消費にどう効くか」という仮説と検証シナリオを先にドキュメントで組み立てて、それから実際に動かすコードを書きました。計画のドキュメントと、それを動かすコードが、同じリポジトリに並んで残ります。 これの何がいいかというと、後から「なんでこの設計にしたんだっけ」となったとき、計画の方を見れば、どんな仮説を立てて、測ってみてどうで、だからこうした、という経緯が全部たどれるんですよね。判断の理由が実装の隣に残っている状態です。お恥ずかしい話、以前はこういう計画や経緯メモは別のドキュメントツールに書いて、そのうち参照されなくなる流れだったので。リポジトリで完結させると「消えない判断根拠」として残り続ける。後で設計を見直すとき、隣のドキュメントを開けば理由がそのまま残っている状態です。 さらに、検証して出た結果（レポート）も同じ場所に書き残しておくと、もっと変わります。 計画 → 実装 → 検証結果 までが1か所にそろうので、その結果をそのままブログやセミナーのネタに使うところまで、一本の線で通るんですよね。「検証したけど、結果どこ行ったっけ」と一回一回情報を探す手間がなくなって、やった検証がそのまま発信の素材になります。 PVの傾向から次のネタが決まる 「隣のネタを拾う」という感覚に近いんですが。Agent Skills まわりの記事が伸びていたので、じゃあ隣のトピックである Issue 操作のネタを調査して記事にしよう、という判断をしたことがありました。PV分析→調査→記事化という一連の流れが、同じリポジトリで完結したんですよね。分析結果のメモと記事のドラフトが同じ場所にあると、「この流れで次は何をすべきか」をAIと一緒に考えやすいし、読んだ分析が次の調査へ自然につながっていく。過去のデータが次の仕事の起点になる、というのが一番わかりやすい実例だと思います。 PVのみを意識してブログを出しているわけではありませんが、データも身近にあることで投稿ブログの分析などがブログ執筆のプロセスに入ってきて、執筆活動の質に少しだけマーケティング的視点を入れることができるようになってきました。 この記事自身が一番の実例 こちらのブログでもデータを集約したことでの恩恵にふんだんにあやかっています。 Karpathy の LLM Wiki や みのるんさんの「Claude Codeですべての日常業務を爆速化しよう」 がモノレポや知識集約まわりで同じ方向のことを書いているのを調査ノートで確認していたので、「集約しようというだけじゃなく、集約すると連鎖が起きるという方向で書こう」と記事の角度を変えられました。巨人たちが同じことを言っているのは、独自の発見というよりむしろ裏付けですね。あくまで参考にさせてもらっている立場です。それでも、調査メモが記事の角度を変えたというのは、先行事例の調べものがそのまま次の判断材料になった一例です。（ちなみに先人たちは巨人って表現をしてきたのはAIですww） なお、検証から記事化するフローの詳細は「 検証→記事化で知見を資産化する 」でまとめています。”知見を資産化”という考え方はこの記事が先行しているので、合わせてどうぞ。スライドも application/slides に置いているので、記事の内容をそのまま流用してセミナー資料も作れます。 過去記事を下敷きにして情報補完する ブログを書いていると「この話、前に別の記事で書いたな。リンク貼っておこう」という場面がよくあります。でも、過去記事を探して、URLを確認して、リンクを貼って……というのを毎回手作業でやるの、地味につらいんですよね。過去記事も同じリポジトリにあれば、Claude が「その話はこの記事で書いてますよ」と拾って、リンク候補まで出してくれる。手で探していたリンク貼りが要らなくなります。 もう一つ、これも小さいけど助かるのが、企画の重複を防げることです。「これ書こう」と思って調べ始めたら、実は企画レベルで前に着手していた、みたいなことがたまにあるんですよね。過去の記事も企画メモも全部同じ場所にあると、書き始める前に「似たやつ、もうありますよ」とAIが気づいてくれる。書き上げてから「これ前にやってたやつだ」と気づく事故が減ります。 どちらも、過去の仕事が文脈ごと同じ場所に残っているから成り立つ話で。別のツールに書き散らしていたら、そもそも探し出せなかったと思います。 始め方は1本のファイルから 一気に全業務を移す必要はないんですよね。おすすめは「まずリポジトリを1つ作る」こと。それだけです。 次に、 docs/research/ みたいなディレクトリを切って、 /research で調査させた結果か、手元の調査メモを1本だけ置く。その1本を起点に、記事やコードから参照が伸びていきます。最初から整えようとしなくていいんですよね。「置き場を1つ決めて1本置く → そこから参照が伸びる」という流れが最小の始め方で、リポジトリに仕事が溜まるほど、使い回せるものが増えていきます。 調査の品質を上げる /research の使い方は「 Claude Codeの調査品質を /research で上げる 」と「 調査→構造化→注入 」で紹介しているので、調査の置き場から始めたい方はそちらもどうぞ。 使ってみての感想 使い始めて一番変わったのは「終わった仕事が消えずに残っていく」感覚ですね。以前は、調査やメモは「その仕事のためだけのもの」で、終わったら参照されなくなっていくことが多かったんです。でも全部1つのリポジトリに入れると、終わった仕事が次の仕事の土台になっていく。同じ時間をかけた作業が、使い捨てじゃなくて積み上がっていく感じがあります。 Second Brain 的な考え方とも近いんですが、ちょっと違うのは、僕にとっての「外部記憶」はむしろブログの方なんですよね（笑）。一度書いて公開した話は、もう頭で覚えておかなくても「あの記事に書いてある」で済む。リポジトリはその手前にある、書く前の素材が全部そろっている場所、というイメージです。自分が思い出せなくても Claude が横断して引き出してくれるので、記憶の代替というよりは仕事の土台になっている感覚ですね。「積み上がる」というのが、いちばんしっくりくる言葉です。 あと、進捗管理やタスク管理も同じリポジトリで回しているんですが、git の履歴がそのままタスクの棚卸しになる、という話は少し長くなるので次の記事に書こうと思っています。近日公開予定です。 今回関連する記事はこちらです。 調査品質・ /research の使い方 調査→構造化→AIへの注入 検証→記事化で知見を資産化 製品モノレポとの違い（CLAUDE.md活用） 履歴でタスクを棚卸しする（次記事・近日公開予定） ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Codeで全業務を1リポジトリに一元管理する作業基盤の作り方 first appeared on SIOS Tech Lab .

PSSLの佐々木です Claude Code・Copilot・Codex といった AI コーディングエージェントは、コマンドを実行できる権限を持ったまま手元のリポジトリの中で動きます。便利ですが、 secret (API token、DB 接続文字列、本番 AWS キー) との同居していることでシークレットが漏洩しないか心配になったので対応策を調査してみました。 この記事では、 ルールで縛っても AI Agent に .env を読まれてしまう情報漏洩リスク その緩和策として Infisical を選んだ理由 Infisical の仕組み (= なぜ AI に「見えない」のか) 個人 AWS アカウントを使った検証での導入手順 についてまとめました。 1. ルールで縛っても AI Agent は secret を読みうる危険がある Claude Code / Copilot 等の主要な AI コーディングエージェントには、運用ルールを書ける場所が用意されています。Claude Code なら CLAUDE.md みたいなやつです。 検証用に立てたプロジェクトの CLAUDE.md にも、こんなルールを書いてみました: - `.env`, `.env.prod`, `.env.*`, `*.pem`, `client_secret.json` などの secret 実体を読まないでください - secret ファイルに対して `cat`, `grep`, `sed`, `awk`, `head`, `tail`, `less`, `python` などで 内容を表示・抽出しないでください - secret 値、DATABASE_URL、SECRET_KEY、SMTP password、RDS password、private key を チャット、docs、issue、PR、ログへ書かないでください しかしここにルールを記載しても何度も裏切られた経験もあり、意図せずAgnetがルールを無視してシークレット情報を見に行く可能性も否定しきれないなと開発をしながら思っていました。 例えば以下のような場合にAgentがルールを無視してシークレットを読みに行く可能性があります 「node dev server が立ち上がらない」→ デバッグのため DATABASE_URL の構造を確認する必要が出る 「ECR push が失敗している」→ AWS profile / credential の状態を見る必要が出る 「 make で env が読まれていないっぽい」→ シェルから env | grep XXX する つまり、 CLAUDE.md だけに頼った secret 管理は 「事故が起きないことを祈る運用」 だと感じていて商用製品の開発をする際にかなりのリスクになりえると思っています。 2. Infisical とは Infisical は OSS の secret 管理プラットフォームです。AWS Secrets Manager や HashiCorp Vault と同じ「secret を集中管理する」カテゴリに属しますが、開発者体験が抜群に良いと思いました Web UI で見て編集できる (json でなく key-value のテーブル) CLI が direnv / dotenv-cli の上位互換 として使える 環境別 ( dev / staging / prod ) + パス別 で分離可能 メンバー単位の RBAC 、誰がいつ何を見たかの audit log Cloud (SaaS) も Self-host (Docker compose) も選べる 無料枠 が個人開発で十分使える 公式に GitHub Star 約 2 万 あって、HashiCorp Vault よりは小規模、AWS Secrets Manager よりは開発者寄りという立ち位置です。 3. 仕組み ― なぜ AI Agent から「見えない」のか Infisical CLI の中核機能は infisical run です: infisical run --env=dev --path=/aws/sandbox -- aws sts get-caller-identity このコマンドの裏では、こういう流れが起きます: infisical CLI (親) │ ├─ 1. ローカルに保存された JWT で Infisical API へ認証 ├─ 2. /aws/sandbox パスの secret 一覧を HTTPS で取得 (in-memory) ├─ 3. fork して子プロセスを作る │ └─ 子プロセスの environ に AWS_ACCESS_KEY_ID 等を export └─ 4. 子プロセス (= `aws sts get-caller-identity`) 実行 └─ 子プロセス終了で memory も解放、secret はどこにも残らない Infisicalを使っていてうれしいポイント ディスクに .env ファイルを一切作らない — AI が cat .env しても “そんなファイルない” 親 shell の env に export しない — AI が env や printenv を打っても見えない (= デフォルトの shell には載っていない) shell history に値が残らない — infisical run -- foo という呼び出し履歴は残るが、secret 値は履歴に出ない 子プロセスが終わったら secret 痕跡ゼロ — RAM 上から消える つまり、AI エージェントが「環境変数経由で secret を盗む」最もカジュアルな経路 (= cat .env と env ) を 両方とも構造的に塞いでいます 。 4. 導入手順 (個人 AWS アカウントで検証) ここからは、自分の個人 AWS アカウント上に検証用の IAM user を作り、その credential を Infisical に登録して AI エージェントから AWS リソースを操作させる、という流れで手を動かしてみた手順です。あわせて、検証用に立てた Django プロダクトの .env 相当の値 (DB 接続文字列、SECRET_KEY、SMTP password など) も Infisical に寄せて、ローカルの .env を消し去るところまでやりました。 4.1 アカウント作成 infisical.com/cloud でサインアップ。Org → Project を作成。 4.2 CLI のインストール # macOS brew install infisical/get-cli/infisical # Linux curl -1sLf '<https://dl.cloudsmith.io/public/infisical/infisical-cli/setup.deb.sh>' | sudo -E bash sudo apt update && sudo apt install -y infisical 4.3 ログインとリポジトリの紐付け infisical login # ブラウザが開いて OAuth cd path/to/repo infisical init # この repo を Infisical project に紐付け (.infisical.json 生成) .infisical.json は project ID と環境名の対応だけ が入っていて secret 値は無いので、git に commit しても問題なし。 4.4 secret を登録 Web UI から登録するのが楽です。複数環境 ( dev / staging / prod ) と任意のパス ( /aws/sandbox /django/app 等) で分けられます。 検証では、個人 AWS アカウントに作った IAM user の credential と、検証用 Django プロダクトの env をこんな感じで分けました: Infisical path env vars 用途 dev / /aws/sandbox AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (個人検証用 IAM user) AI エージェントから S3 / EC2 / SSM などを叩く検証 dev / /django/app DATABASE_URL / SECRET_KEY / SMTP_PASSWORD 等 検証用 Django アプリの実行時 env これで手元の .env は完全に削除。値は全部 Infisical 側にだけ存在する状態にしました。 4.5 実行 # AWS 操作 infisical run --env=dev --path=/aws/sandbox -- aws sts get-caller-identity # → arn:aws:iam::xxxxxxxx:user/sandbox-user # Django 起動 infisical run --env=dev --path=/django/app -- python manage.py runserver これで OK。 .env ファイルもシェルへの export も一切無し。 5. 検証してわかった恩恵 5.1 AI エージェントが構造的に secret に触れなくなった 検証では Claude Code に「個人 AWS アカウントの S3 バケットを一覧して、不要なものを削除して」みたいなタスクを投げてみました。 infisical run 経由で AWS 操作を委任しても、Claude は そもそも secret 値を「知る」術がない 。例えば: infisical run --env=dev --path=/aws/sandbox --silent -- \\ aws s3 ls これを Claude に実行させても、Claude が見られるのは: コマンドの引数 (= 公開情報) コマンドの出力 (= 私が許可した情報) だけ。 AWS キー本体は Claude のプロセス空間にも会話履歴にも入りません。 検証用 Django アプリ側でも同様で、 .env を消した状態で Claude に「dev server を立ち上げて動作確認して」と頼むと、 infisical run 経由でしか起動できない。エージェントが好奇心で cat .env しても ファイルが存在しない ので空振りに終わります。実際にやらせてみても、 DATABASE_URL や SECRET_KEY の値が会話履歴に出てくることは一度もありませんでした。 5.2 検証用 IAM user を分けやすい 個人 AWS アカウントで遊んでいると「これは AI に渡していい権限」「これは自分が手でしかやらない権限」を分けたくなります。Infisical のパスで切るとそこが綺麗: # AI に渡していい権限 (read 中心、限定リソース) infisical run --env=dev --path=/aws/sandbox -- <command> # 自分しか使わない権限 (IAM 編集、billing 系) infisical run --env=dev --path=/aws/admin -- <command> IAM user 自体は別々に作って、Infisical 側でパス権限を分けるだけ。エージェントには /aws/sandbox だけアクセスできるトークンを渡す、みたいな運用が現実的にできます。 5.3 検証が終わったら剥奪が一瞬 個人検証あるあるで「検証終わったけど IAM key 消し忘れて放置」が起こりがちですが、Infisical に集約しておけば Web UI で値を消すだけ。 .env が複数のリポジトリに散らばってる状態より圧倒的に管理が楽でした。 6. まとめ AI Agent と一緒に開発する時代、 .env をローカルに転がしておく運用は 「ルールで縛っても、いつかは事故る」 可能性があります。 文章ルール ( CLAUDE.md ) は「お願い」レベル AI Agent はタスク遂行のために env を覗くことがある (悪意なしでも) 一度履歴に入った secret は AI ベンダー側に永続化される Infisical の infisical run -- <command> 方式に切り替えると、 .env ファイルがそもそも存在しない → cat で出ない shell env にも default で乗らない → env / printenv で出ない 子プロセスのライフサイクル内だけで secret が生きる それでいて direnv 同等の手軽さで開発が回る 完全防御ではないが、 カジュアルな漏洩経路を構造的に塞いだ上で、AI エージェントとの共存を成立させる ための最小コストの一手として、強くおすすめできます。 個人 AWS アカウントでの検証レベルでも、 .env を消して Infisical に寄せたことで「エージェントに何を喋らせても secret が混入しない」という安心感は段違いでした。本番投入前のサンドボックスとして手を動かしてみる価値は十分あると思います。 参考リンク Infisical 公式 Infisical CLI ドキュメント Anthropic Claude Code 公式 GitHub: Infisical/infisical ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AI エージェントに.envを読まれたくなかったからInfisicalを導入てみた first appeared on SIOS Tech Lab .

はじめに こんにちは、サイオステクノロジーの小野です。以前、HelmOpsについて解説しました。 GitOpsだけじゃない！新たな選択肢「HelmOps」とは？ HelmOps環境を構築するCDツールは様々な種類があります。（ex. Rancher Fleet, ArgoCD, Flux CD） その中でもRancher FleetはHelmOpsを簡易に構築することが可能です。 今回はRancher FleetのHelmOps機能を使って、実際に自動デプロイできることを紹介したいと思います。 HelmOps設定 前提条件 Rancher環境でHelmOps実施 Rancher v2.13.3 Fleet v0.14.3 設定方法 Rancherの管理コンソールのRancher Fleet管理画面を開きます。左メニューのヨットマークが目印です。 Rancher Fleet画面 「Create Apps Bundle」を押下して、HelmOpsを作成することで、HelmOpsの設定が可能です。 HelmOpsを選択 HelmOps実践 以下のHelmアプリをHelmOpsでデプロイします。replicaCount数のPodが立ち上がり、ClusterIPのService設定で公開されているhttpbinのサンプルアプリをデプロイする例を考えます。 # Chart.yaml apiVersion: v2 name: sample-app type application version: 0.1.0 appVersion: "1.0" # valuse.yaml replicaCount: 1 image: repository: kennethreitz/httpbin pullPolicy: IfNotPresent tag: "latest" service: type: ClusterIP port: 80 このアプリをデプロイするために以下のようにHelmOpsに設定します。 Bundle名：test-helmops（HelmOpsのバンドル名を指定） Release名：demo-sample（Helmのリリース名を指定） Source Type：Repository Repository URL：<HelmリポジトリのURL> Chart：sample-app（HelmOpsでデプロイするHelmチャート名を指定） Version：>=0.1.0（一定バージョン以上を継続的にデプロイしたい場合は「>=0.1.0」のように設定する） Values：設定しない Deploy To：test-cluster（HelmOpsでデプロイする対象のクラスターを設定） Additional Options.Target Namespace：demo-ns（デプロイするNamespaceを指定） Authentication：None（Helmリポジトリの認証がある場合設定） Polling：Enable Polling（継続的にデプロイする場合、Pollingを有効にする） 設定後、HelmOpsのBundleが作成されて、Rancher Fleetの管理画面からデプロイ状況を確認できます。 デプロイ状況を確認 デプロイした先のクラスター管理画面を開くと、自動的にサンプルアプリがデプロイされていることが確認できます。 サンプルアプリのデプロイを確認 Podが1個デプロイされている 80ポートのClusterIPで公開されている Helmリポジトリ内のサンプルアプリを更新して、自動的にデプロイされているアプリも更新することを確認します。 サンプルアプリのChart.yamlとvalues.yamlを以下のように更新します。 # Chart.yaml apiVersion: v2 name: sample-app type application version: 0.2.0 appVersion: "1.0" # valuse.yaml replicaCount: 2 image: repository: kennethreitz/httpbin pullPolicy: IfNotPresent tag: "latest" service: type: ClusterIP port: 8080 更新した上記のファイルをHelmリポジトリにアップロードすると、以下のようにデプロイされているアプリも自動的に更新されることが確認できます。 Podが2台に更新されている 8080ポートのClusterIPで公開されるように更新されている おわりに Rancher FleetのHelmOpsについて解説しました。CD環境を構築するには大きなコストがかかりますが、HelmOpsはHelmリポジトリ内のチャートファイルを指定するだけで簡単にCD（継続的デプロイ）環境を構築することが可能です。ぜひ手軽に試してみてください。 参考 https://fleet.rancher.io/how-tos-for-users/helm-ops ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Rancher Fleetで簡単に実現！HelmOpsを使った継続的デプロイ(CD)の実践 first appeared on SIOS Tech Lab .

こんにちは！ 今月も「OSSのサポートエンジニアが気になった！OSSの最新ニュース」をお届けします。 2017 年から潜伏していた Linux カーネルの深刻な脆弱性「Copy Fail」が、極めて重大なリスクとして速やかな対策が求められています。 「Linux」に極めて重大な脆弱性–「Copy Fail」発覚 https://japan.zdnet.com/article/35247165/ GTIG は AI を用いて開発されたと思われる zero-day exploit (ゼロデイエクスプロイト) を使用する脅威アクターを特定しました。 GTIG AI Threat Tracker: Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access?hl=en アメリカのセブンイレブンは、ShinyHunters というサイバー犯罪グループによるサイバー攻撃により、同社のシステムが侵害されたことを認めました。 7-Eleven confirms data breach claimed by the ShinyHunters gang https://www.bleepingcomputer.com/news/security/7-eleven-confirms-data-breach-claimed-by-the-shinyhunters-gang/ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【2026年5月】OSSサポートエンジニアが気になった！OSS最新ニュース first appeared on SIOS Tech Lab .