実物を見て仮説を立てて主張する 仮説を実物と見比べて反論・主張する それに対して実物と見比べて反論・主張する それに対して実物と見比べて反論・主張するという批判的思考の連鎖を、codex-consultationでは実装しているshokai.icon 詳しくはCodex CLIと相談するAgent Skillの相談の深さを調整するで語っているこれを丁寧に守るプロトコルの上で、AI同士に問答を往復させて精度を上げている 人間には無理 次第に面倒になる、時間がなくなる Time Is Moneyだから途中で切り上げて実行に移した方が効率的という事になる しかしAI同士なら金で時間を解決できる えんえん長文の主張を作り合って、細かい所までツッコミしあえる ルールは崩れ、Time Is Not Moneyになっているこれを「相談」と命名してAgent Skillsとして登録する事で、人間は軽い気持ちで相談したのにAI側で重い批判的思考の1〜2往復が行われてしまうようにしたのが、codex-consultationですshokai.icon

Dependabotやrenovateなどの依存アップデートpull requestに関する作業を統合したAgent Skillのセット（plugin） shokai/agent-skillsに含まれている dependabotによるライブラリやNode.jsの更新を毎日やる為に作ったshokai.icon機能 Claude Code on the webのroutineで定期実行する Dependency update reportを作成、Githubにコメント投稿 library-update-review skillの改良版 dependency-update-report skillとして単体でのレポート作成も可能 自動修正 リポジトリ内の修正方針ドキュメントに従う 自動merge する・しないをリポジトリ毎に切り替えれる Slackなどへの完了報告 上を行うroutine promptの作成 dependency-update-setup-routineというskillを使う Claude Code on the webのroutineへのセットアップもやってくれる

ライブラリ更新レビュー手順書 Agent Skills版の事deprecatedです。これを改良したdependency-update skillを使ってくださいshokai.icon

software-factory-mode pluginの中の、現在の基本skill 移動式Software Factory (2026秋)として、GyazoやHelpfeelの開発環境にshokaiの考えるSoftware Factory 2026秋相当の作業フローを持ち込みたいを実装したもの ほぼ正気を疑う技術 - bugのないvibe codingを目指してで説明してる流れなのだが、内容を知らない人でも、skillを起動するだけでレールに乗れる user領域にインストールしておけばどこのリポジトリにでも持ち込める https://github.com/shokai/agent-skills/blob/main/plugins/software-factory-mode/skills/software-factory-mode-2026aki/SKILL.mdこのSkillのお陰でAIを並列に3セッションぐらい回し続けていてもぜんぜん疲れないshokai.icon 決まり事を一切考えなくて済むようになる 要求・仕様の擦り合わせ、実装内容をセカンドオピニオンAIでレビュー、レビュー結果を吟味してどれを取り入れるか考える、良い感じになったらプルリク作る、プルリクの体裁整えて再レビュー、レビュー結果を吟味してどれを取り入れるか考える(2) といったプロセスの状態説明を、社内ドキュメントと同期したり、githubのラベルやdraft / ready for reviewの状態で表現したりする事から解放される 考えるべき事を考える、意思決定する、それだけに集中できる準備 作業はClaude Codeで行う セカンドオピニオン役としてCodex CLIをインストールする shokai/agent-skillsのskill全てをclaude側のuser環境にインストールし、skill storeのauto updateを有効化する

software-factory-mode-2026aki skill v0.13.0の基本フローはこうなっている 1. 着手前に不明点・懸念事項をユーザーに質問し、解消してからplan modeに入る 質問で停止 2. 変更が一段落したらbug確認 3. formatterとlinterを実行 4. 必要に応じてcommit。default branchには直接commitしない 5. pushはユーザーの明示的な指示を待つ 指示まで停止 6. PR作成を指示されたらdraftで作成し、対話コンテキストをexportし、インラインレビューコメントの草稿を書く 7. 草稿を提示したら投稿方法をユーザーに確認する。AIが投稿するか、ユーザー自身が投稿するか 提示で停止 8. sanity-reviewはユーザーの指示を待ち、指摘対応をpushし、対応内容を簡単にコメント投稿してからready for review 指示まで停止 9. PRがready for reviewに切り替わったら、そのPRがsquash and mergeでcommit messageを指定できる場合は、タイトルと本文の草稿を提示し、「指示されたらこの草稿でsquash and mergeする」と告げる 指示まで停止 10. mergeを知らされたら開発環境を後始末するこれらは全てmemory、上位skill、CLAUDE.md、プロンプトでブレーキを外したり、挙動を上書きできる

Cosense開発環境のSoftware Factory化で実装した、私の考えるベストな開発フローをGyazoやHelpfeelにも持ち込みたいshokai.icon Software Factory (2026秋)で説明しているやつ plan立てて実装し、codexと相談してbug修正、pull request立てて対話コンテキストexport、インラインレビューコメントの草稿出す、sanity-reviewかける、レビュー報告書読んで修正 これを、可能であればworktreeで並列にやれる環境しかしCLAUDE.mdを書き換えたりと大手術になる 他の人の開発体験も変化するので、説明…の前に調査・ヒアリングも必要単体のドキュメントをポンと置いたらほぼ同じ開発フローが再現できるようにしたい ポータビリティを上げたい 「こういう時はこうする」のドキュメントをAgent Skillの中に入れておいて、開発開始時にshokai.iconが手動でskill起動する この方式なら他の人にも試してもらいやすそうやらない事 .claude/settings.jsonの設置。Agent Skillは自分のマシン側にインストールしておけばとりあえずヨシ調査

良いところ githubをforkするよりも効率的 大本のskillの更新に自然についていけるわかりやすい例 software-factory-mode-2026hashi skill 人間に確認を求める、指示を待つ系のブレーキを解除している sanity-review 内部で使うcodex-consultationの説明深度を「よく相談」で固定している codepatrol skill codex-consultationの説明深度を固定 さらにsubagent-consultationの使用を禁止しつつ codexのmodelに下限も設定。下位tierのmodelを禁じる software-factory-mode-2026aki skillのブレーキを全て外す上書き Cosense Skill & CLIの読解深度も「よく読む」に固定skill側からoverrideを求める事もできる

codepatrol skillに内蔵された修正難度順トリアージ機能 subagent向けの手順書 このskillを直接起動するのではなく、指揮役である親agentに/codepatrol 深刻度Highに絞ってトリアージしたい等と依頼すると、複数のsubagentを連続起動しマネジメントしてくれる 親はFable 5.1がよい全領域コードパトロールのやり方をskillに取り込むで実装された

codepatrol skillに内蔵された、脆弱性修正の自動化機能 subagent向けの手順書 このskillを直接起動するのではなく、指揮役である親agentに/codepatrol 自動修正したいと依頼すると、複数のsubagentを連続起動しマネジメントしてくれる 親はFable 5.1がよい信頼性の高い単一の修正pull requestを作る部分はsoftware-factory-mode-2026aki skillになっているが、この部分は疎結合で、差し替え可能である お好きな自動修正を使いください背景はcodepatrol自動修正工場をagent skill化するをよく読んでくださいshokai.icon

software-factory-mode pluginの中のskillの1つ https://github.com/shokai/agent-skills/blob/main/plugins/software-factory-mode/skills/software-factory-mode-2026hashi/SKILL.md複数のリポジトリでのsoftware-factory-mode-2026aki skillの運用を通じて、様子を見ながら徐々にブレーキを外すを続けていったmemoryを元に作ったshokai.iconAgent Skillの文言のoverrideという汎用的なやり方をしているclaude codeで/hashiと入力するとすぐ出てくる

shokai/agent-skillsに入っているpluginの1つ含まれるskill software-factory-mode-2026aki skill software-factory-mode-2026hashi skill

これ間違えて認識してる人多そうshokai.icon AIに全部任せる v.s. 最終責任は誰が取るんだよ、という構図の議論は的外れです いつかすごい賢いAIやツールが来て、全部任せるか、自分で責任取るか、という世界観 少なくともshokai.iconのやってる領域はそうならない。判断は時と場合によるから私はほんの1行のテキスト修正や、git commitコマンド、Githubのmergeボタンを押すような些末な作業も、AIでやっています 面倒くさがっているわけではありません 将来的にブレーキ外して完全自動化するためです 1. まず全ての作業をAIを介して行い、判断だけ人間に残す 2. そして人間の判断を十分に言語化し、仕組みを作れたら、判断というブレーキを外せる すると だんだんAIの作業品質を信頼できるようになってくる これでその工程は完全に自動化できる 様子を見ながら徐々にブレーキを外すという方針に基づいている 具体的なプロセスはAgent Skillは現実の問題を解決した実績あるmemoryから作れに書いたshokai.iconそのためにはレポート作成です 精度の高いレポート・報告書を作る手順書を作る事が、判断の自動化に繋がる

コードパトロールレポートをcodepatrol-triageで処理すると、脆弱性のリストを3×3に分類できる こう整理したら一気に自動化が受け入れられた脆弱性修正では 深刻度が高く、修正難度が低い問題ほど、リスク許容できる 脆弱性を深刻度 x 修正難度のmatrixにプロットすると良い table:修正難度と深刻度 修正難度1修正難度2修正難度3 深刻度High自動修正自動修正？人間が見る 深刻度Medium自動修正人間が見る人間が見る 深刻度Low自動修正人間が見るやらなくていい 人間が見る、とは コードを手で書くという意味ではない 人間がsoftware-factory-mode-2026aki skillを使いつつ、細かく意思決定しながら進める

shokai.icon作の脆弱性診断ツール Agent Skillとして実装されている Opus 4.6 + GPT-5以上が同時に使える事を前提に作ったSkillです。Sonnet等で起動しても停止するようになっていますshokai/agent-skillsからインストールできる https://github.com/shokai/agent-skills/tree/main/plugins/codepatrol動作 /codepatrolで起動 調査対象領域リスト targets.md 初回起動時に作成される サーバー側のコードのcontrollerのリストと、内容のサマリー 「調査対象リストを更新しろ」で再作成できる 調査観点リスト checklist.md 初回起動時に作成される Skillに内蔵された、典型的なSaaSに共通なセキュリティチェックリストに

codepatrol-triageで実装した分類 1. 仕様変更のための意思決定が必要ないbug 2. 仕様変更のための意思決定が必要だが、レビュアーへの説明は容易なbug 3. データモデルやセキュリティモデルが大きく変化する、ユーザーに周知が必要、等でレビュアーへの説明が大変なbug1は、software-factory-mode-2026aki skillを正しく使えるなら誰でも直せる プロセスが正しければ直せる それぐらい、単純に埋めれば直る穴ならば周りの建物を壊さずに修復できるプロセスがもう確立している ソフトウェア開発者以外でもbug修正に参加できるという事では、まったくない 「stripeからのwebhookがinvalidな場合は400を返して良いですか？それとも200のまま処理分岐しますか？」これぐらいの情報量の質問は複数されるので、サッと意思決定できる知識や調査能力は必要2以降が難しくなる3は、そのプロダクトの開発者自身が後先考えながら設計修正しないと無理 プロダクト外から来たソフトウェア工場長の手には負えない代物。今は。Software Factoryの進化によって、それなりに設計のセンスがある人なら3も修正できるようになるだろう ユーザーへの周知、データマイグレーションの見守り、をAIがやれるようになれば

楽だからですshokai.icon AIにはドキュメントとコードの読み合わせをやってもらう sanity-reviewや、pull requestの概要欄とレビューコメントを書きました。間違いや説明不足な点があれば指摘してくださいなど、正気を疑うツールが使える状態になる pull request概要欄は人間とAI向けの宣言を書く場所と考えるコードレビューやbugの確認をする時、pull request概要欄に書かれた宣言が役に立つ確認項目が3つある場合 AIに「JSをTSに書き直しました。動作が変化してしまっていないか確認してください」と指示するのではなく pull request概要欄に「いくつかのJSをTSに書き直しました。動作は変更していません」と書く AIに「API v2を追加したが、API v1の動作は変化してしまっていませんか？後方互換性を維持したいので確認してほしい」と指示するのではなく pull request概要欄に「API v2を追加した。後方互換性を維持するため、API v1の動作は一切変更していない」と書く AIに「このブランチで新規実装したserver API全てに、testの実装漏れがないか確認してください」と指示するのではなく pull request概要欄に「新規実装した全てのserver APIは、アクセス権限を持たないユーザーを拒否する事を確認するtestが実装されている」と書くそしてAIに「概要欄の説明とコードの実装に齟齬が無いか確認してください」と指示する

vibe codingによる実装後の、自分の理解が正しいか確認するためのプロンプト まずAIと一緒に作業した結果の、最終的な仕様を自分なりに説明しなおす それをAIに確認してもらう事で、自分の理解が正しいかわかる 結構勘違いしている事がある 説明不足な点もかなり良い塩梅に指摘してくれる 対話・相談してコードを書いてbug修正も一緒にやった、十分なcontextを持ったAIだから 人間が読むのにちょうど良い粒度の概要欄になる typoも指摘してくれるpull requestの概要欄は人間が手書きするようにしているshokai.icon AIにpull request概要欄を書いてもらうのは機会損失である プロセスとしてCosenseに書いた概要をpull requestの概要欄にコピペしない。自分の言葉で書き直すの邪魔にならない点も、良い なぜpull request概要欄を丁寧に書いているのかを満たしつつ丁寧に、正確にやれる 自分で書く。それをAIにレビューしてもらう 手を動かしたAIと、構想を練った自分の間の認識違いを無くす 自分が仕様の詳細を勘違いしている事がわかったりする 考えるために書く。人に伝えるために書くと、ようやく、実は必要なのはコレではないのかもしれない、とか気づいたりする

shokai.icon製Agent SkillsのClaude Marketplace https://github.com/shokai/agent-skills特定プロダクトの開発に用途が限定されない、汎用的なSKILL.mdが公開されている収録されているもの sanity-review ライブラリ更新レビュー手順書 Agent Skills版 Claude CodeからCodex CLIを呼び出して相談させるAgent Skill 対話コンテキストをテキストファイルにexport/importし、別のAI sessionに引き継ぐAgent Skill 定石外発想Agent Skill codepatrol skill software-factory-mode plugin kuden plugin skill-usability-test skill dependency-update skill remote-claude-session skill

Helpfeel社内では、トリアージを「大量の偽物の中から本物を見つける」という意味で使われてしまっている 例：「そのbugが再現するかトリアージして」 もしかしたら多くのソフトウェア開発の現場でも、同様かもしれないだいたいバグ報奨金プログラムのせいshokai.icon 自称セキュリティリサーチャーによる再現しない大量の報告を選別するという、本来のトリアージとはかけ離れた言葉になってしまったトリアージの元々の、医療での意味 実際に困っている相手のうち、誰を優先対処するか決める 自分のリソースと相手の状態を鑑みて決める、という意味だったのに 大量の偽の患者から、本物の患者を見つけ出す作業に変化してしまった修正難度順トリアージは真の意味でのトリアージですshokai.icon

AI対話コンテキストをexportするAgent skill conversation-context-importとセットで使うshokai/agent-skillsからインストールできる 対話コンテキストをテキストファイルにexport/importし、別のAI sessionに引き継ぐAgent Skillで実装し、その後marketplaceにリリースした特に、やらない事とその理由に着目して分類・定型化してexportする やった事を引き継ぐ作業は既存の物が多数あるから AIエージェント本体にも組み込まれているし 人間も、誰でもみんなやってるでしょう。「今回やったことをまとめてくだい」とか やってない事、やらないと決めた事の構造化と引き継ぎはイチイチめんどくさいので、Agent Skill化したという事ですClaude Codeの/compactコマンドとも相性が良い /compactは、やらない事とその理由をほぼ全て捨ててしまう やった事とその理由はかなり引き継がれる compact後に必ず対話コンテキストを読んでくれている もし読んでくれてなかったら手動でconversation-context-importしてください

例えば 状況認識、問題の言語化、解決方法をリストして選択、結論とか 8つの典型的なセキュリティレビュー観点それぞれについて記述させるとかAIにいきなり結論を出させるな かといって自由にも考えさせるな フォーマットを決めて、毎回同じ様に章立てして、結論まで書かせる library-update-review skillやsanity-review、同僚watchのように 形式を揃えたレポートなら速読できる 人間が、AIの出した結論も、それに至る論理も、どちらもレビューできる だんだんとAIの出力を信頼できるようになる AI modelの性能向上も体感できる一旦レポートという形式にすると、それを別のAIでレビューしやすい 別のAI modelで subagentで codex-consultationで レビューで重要なのは検証ではなく主張の方

#AIエージェントにプログラミングさせる時のパターンDevinを見てこういう使い方が一番強みになるだろうなと思ったけど、Devinはボンヤリしているので結局Claude CodeやCodex CLIでやってるshokai.icon スクリーンショットはClaude Codeだが、こういう感じです 2025年5月からwebページを読めるようになって、便利になったこうではない 生成AIにお願いしてコードを書いてもらうこういう用途です pull requestのコードと、 https://scrapbox.io/terms や /help-jp/セキュリティポリシーなどのドキュメントの齟齬がないかDevin.iconにチェックしてもらう 理由あってセキュリティヘッダをゆるくする場合に、バグバウンティプログラムの概要欄と読み合わせて、除外項目として指定した方が良い場合は教えてもらう 新規エラーと、最近のpull requestのコードの対応付けして、実装者に通知する Sentryやcloud loggingから拾う 顧客からのbug報告と、最近のpull requestのコードの対応付けして、実装者に通知するどれも既存ドキュメントと新規実装したコードの読み合わせをしてもらう、という点で一致している

批判的思考の連鎖はこの考えから来ている やった事だけでなく、conversation-context-exportでやらない事とその理由も列挙して それらをsanity-reviewで検証するやり方レビューしにくいPull Request 「できました☺️」「言われた通りに作りました、あなたの指示通りです」レビューしやすいpull request 「こういう問題があって、こう実装しました、仕組みはこれ。実装しなかった案はこういうもので、不採用理由はこれ」後者には反論しやすい 問題認識が間違っているのではないか 問題認識が正しいとして、解決方法が間違っているのではないか 解決方法の実装詳細が間違っているのではないか 採用しなかった案の方が良いのではないか？ほんの少し調整すれば〜つまり主張があれば反論しやすい。そして反論こそが検証ですshokai.icon

最近はドウシシャ 足元ヒーターではなくAmazonで800円ぐらいで売ってるUSB電熱中敷きを、無印のイ草スリッパの裏に貼って使っている 同じようなのが「USB 中敷き」とかで検索するとたくさん出てくる どれでもいいと思う。安いのを買おう。どうせすぐ壊れるのでスリッパは最近はもっと薄底の方が良くなってきたshokai.icon電源 5V 1AのUSB-A 念の為、パソコンのUSBポートには接続しない方がいい直接スリッパの中にセットすると熱すぎる スリッパの裏に貼るのがちょうどよい い草の食感が良い じんわり温かい

このwikiのこと 2016年春ごろ作った ほぼ今のこのwikiに機能は吸収された (2016/09/14) サーバーサイドレンダリングまわり以外？URL hostname/wiki名/page名になっている wiki名の部分を変えると自由にwikiが作れるようになってる動機 メモ帳 兼 blogがほしかった WYSIWYGいいよね publishする画面と同じ見た目で編集したい でもツールバーごちゃごちゃは嫌、簡単な記法で書きたい 他人にはサーバーサイドレンダリングで見せれて、RSSもあってblogとして使える奴が欲しい Reduxとkoaとasync-awaitを試したかった コード片を貼り付ける場所が欲しい主な機能 がんばって書いたり覚えたりしないでも見やすく表示する編集

熟練者と同等のCosense読み書きを実現するハーネスとAgent Skill更新テストshokai.icon (2023/4/6 20:21)リンクパスワードつきgyazo private projectの画像 更新通知テスト

結論 今後人間を増やさず、新製品を未来永劫作らない会社は階層ドキュメントツールで文書共有していても大丈夫階層整理（フォルダわけ）するWiKi等のドキュメントツールを、複数人のグループで使っていると破綻するパターンがある。原因は大きく分けて2つ 1. 人が増える 2. ルールが増える単体ではまだ根性でなんとかなる。しかし2つが合わさると、「WiKiマスターにお伺いを立ててどのフォルダに入れるか決めてから書いてください」という謎の運用ルールができたり、間違った階層に配置すると「ちゃんとルールに従って整理しろ！」と滅茶苦茶怒られたりするようになって、誰も書かなくなる。1. 人が増える 人間は増える。（会社でもサークルでも） あらかじめ綿密に分類ルールを決めていると、新入りへの周知が面倒くさい ルールを決めた人からすると、せっかく決めたルールを理解せず適当なフォルダに入れる人がアホに見えてイライラしてしまう

これはAI Engineering Summit Tokyo 2026の発表資料を、さらに社内勉強会向けに更新したものです 右のメニューのStart presentationでスライドになります AIを使ったオススメ開発フロー 2026年春や Pull Requestの書き方 2026年春のAIコーディング対応バージョンとセットになった話です よりツールの役割や背景にフォーカスした切り口となっておりますAIによって80点程度のコードを書く速度は劇的に上がりました。問題は、出てきたコードを誰がどう信じるかです。Helpfeelはインフラ・金融機関向けにもサービスを提供している為、開発者はAIを盲信せずコードを理解する必要があります。本セッションではAI対話コンテキスト抽出・批判的思考の連鎖・sanity-review等の自作ツールを使い、説明と実装の一致から、やらない事とその理由の妥当性までを確認する開発手法を紹介します。AIに実装させるだけでなく、AIに正気を疑わせる開発プロセスです。こんにちは。橋本翔 (shokai)ですshokai.icon Helpfeel Cosenseのプロダクトマネージャー イオンの丸鶏(1200円ぐらい)に、S&Bの鳥香草焼きスパイスミックス(100円ぐらい)とオリーブオイル塗って、ヘルシオで焼くのにはまっています 鶏の丸焼き今日の話

春といいながら書いたの6月だけど、私は3月からこうやってますので許してくださいshokai.iconこれは正気を疑う技術 - bugのないvibe codingを目指しての第二部の部分です 登場するツールの役割は第一部の方を読んでください 書き出してみると、意外とややこしい事やってるなと思ったshokai.iconPull Requestの書き方 2026年春のAIコーディング対応バージョンもセットでどうぞshokai.icon環境 Claude Code (Opus)とCodex CLI (GPT5.5-high以上)を使っています Sonnetにソフトウェアの設計能力はありません。これは指示に基づいて1つのファイルを少し編集する為の、単純労働者です 基本的に全てOpus 4.5で作業した方が良いのではないか？ IMEの辞書によく使うプロンプトを入れておく これはとても便利 daiiz.iconmiyamonz.icon hiroshi.icon こういうのは CLAUDE.md とかに書いてもよさそうかもと思った まさに最近はそんな感じ。AIに「次はこれですね」とガイドしてもらっていますshokai.icon