以下の2つは独立した要素です 1. 必要十分な情報を記録し、それを必要としている相手に、良いタイミングで伝わる事 相手は未来の自分かもしれないし 間違いを訂正してくれたり、考えを発展させてくれる他人かもしれない 2. 多くの人にウケて、buzzる事相手の選択、タイミングの選択 それが難しいからといってSPAMまがいの行為を行うのは間違っている インターネット上の言葉遣いが荒くなるのは推薦サービスが短期的なせい価値がある情報でも、多くの人に理解可能であるとは限らない むしろ理解不能かもしれない というか 誰にでも簡単に理解可能な程度の内容に価値があるのか？ 俺がやっているのは誰でも簡単にご理解いただき、「これはすごい」とかシェアされる程度の事なのか、という虚しさを感じてしまう 8割がわからない位で丁度いい 良いものは他人に「良い」と発見される以前から、変わらず存在している

/remote/We are remote #1 共有メモ (2017年) /nota-techconf/増井さんの発想法を掘り下げる-次々と便利なサービスを生みだす方法 (2021年)

どうしてもWebSocketが使えない顧客向けに作った緊急レスキューモード Cosenseのフル機能は使えません リアルタイム共同編集できません。本文は1人ずつ編集してください音声付き解説

2026/6/10ごろに社内に書いたページですずっと調査してる 不明点・懸念事項があれば何でも私に質問してください。明確になってからplan modeに入りましょうと指示すると3つのExplore agentで調査しはじめる Opusでは1つか2つだった Claude CodeのAsk User Question Toolを出してこちらの回答を待っている間も、Explore agentがコードを読み続けている 調査と入力待ちを並列化しているtokenコストは実測でOpusの10倍になったshokai.icon tokenあたりのコストはOpusの2倍だが こっちの入力を待ってる間もずっと調べてるから10倍かかる LLMのmodel部分はOpusとあまり変わらないんじゃないか？という感触がある。なんとなく。 富豪的で非同期な挙動の戦略が、賢さの秘訣なのではないか？1を聞いて10を知るような挙動をしている project毎にopt-inにしたいshokai.icon

2026/3ごろに社内projectに書いたものを持ってきた 正気を疑う技術 - bugのないvibe codingを目指してのショートバージョン前提レビュアーは、AIと実装者の間で何が相談されたのか見えません 見えたとしても、読みきれません これをどうにかする必要がありますshokai.icon 社内規定ではないが、まあ普通に考えてそうだよなという私のやり方を書きます紹介しているAgent Skillは、大抵のAIコーディングエージェントで動くはずです 私はClaude Codeを使っていますが 少なくともCodex CLIでは動くように作っています 本当に普通のAgent Skillなので、たぶんCursorやCopilotでも動くはずです人間にコードレビューを求める前にやるべき2つの事

AIで調査・検討・設計・実装が一体化したのと同じ レビューは調査・検討・設計 bug修正は実装

先に仕様書を作り、それをSingle Source of Truthとして開発を進める手法AI以前からあった。AIをコントロールする方法として使われたりしている個人的にはAIの長所であるスピードと柔軟さを潰しているなあと思うshokai.icon 作って試す ↔ chatで相談で仕様を捏ねていく、を反復できるのが便利なのに そこで開発駆動仕様書です

仕様書駆動開発の逆AIと相談して色々検討し、最適な設計を考え、そして実装する vibe codingの強みは手数。いろいろ試そう AIで調査・検討・設計・実装が一体化したのだから実装した後、出力・修正を繰り返したコードとAI chatのAI対話コンテキストを元に、仕様書を生成しない 生成せず、自分で書く 自分でAIと相談して生成させたんだから、宣言的な仕様書ぐらい書けるだろう 対話コンテキストは参考にしていいけど、コードは自分で読めよ この仕様書をpull request概要欄にして、sanity-reviewを行う コード読んで宣言的な仕様書を書けない場合、正気ではない AIでレビューとbug修正も一体化した状態になる

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

OpenAIのAIコーディングエージェント https://developers.openai.com/codex/cli/ https://github.com/openai/codexインストール $ npm install -g @openai/codex@latest https://www.npmjs.com/package/@openai/codex をインストールしましょう https://www.npmjs.com/package/codex と間違えないよう注意名前からCodexのCLI版のように見えるけど、別にそういうわけではないshokai.icon たぶんClaude Codeをパク…参考にして作っている

2026/6/8, 9https://ai-engineering-summit-tokyo.findy-tools.io/2026-summer2026/6/8 12:10から話しますshokai.icon https://ai-engineering-summit-tokyo.findy-tools.io/2026-summer/ttable?m=2026-summer/timetable/IkntxfN6

どんな質問にも答えられるFAQサービス https://helpfeel.com/ 株式会社Helpfeelがやっている

こうする プロセスやロジックをダブルチェックするshokai.icon 正気を疑うという事ですこうではない レビューというと完成物をダブルチェックする行為を思い浮かべがちだが、そうではない正気を疑うとは プロセスや考え方をチェックする 現状認識・分析 この機能が何を目的とした機能で、どういう挙動をするのかを軽く説明する bugの検証方法、このbugからどういう教訓を得たのか bug修正ではなく新機能の場合も、これが重要 どこを見ているかをチェックする

https://github.com/shokai/agent-skills/blob/main/plugins/library-update-review/skills/library-update-review/SKILL.md

Agent Skillにしました ライブラリ更新レビュー手順書 Agent Skills版AIコーディングエージェントにドキュメントとコードの読み合わせ機になってもらうプロンプト対象 DependabotやRenovate等が作ってくるnpm更新pull request 人間が作成した、作りかけのライブラリ更新pull request他の言語に対応する場合 このプロンプト内のpackage.jsonやnpmjs.comなどの文言を、Gemfileやrubygems.orgに書き直した方が、たぶんうまく動きますshokai.icon ただ、そのままでもRailsプロダクトのgem更新でうまく動いたという報告もありますcode:prompt(markdown) # ライブラリ更新のレビュー手順書 ライブラリを更新する変更をレビューし、必要に応じてバージョン間のmigrationや、breaking changeへの対応も行う為の手順を説明します。

昔はAuto Compactに任せてしまっていたけど、最近は手動実行してるshokai.icon コンテキストが長くなってきてAIの動作が重くなってきたな あるいは、作業毎の料金の伸びが凄くなってきたな、と思ったら/compactを実行している

conversation-context-exportおよびconversation-context-importとしてmarketplaceにリリース済みshokai.iconfrom 1人あたり1日20プルリク出す世界を考えるpull requestにおいて、やらない事とその理由が、レビューにも、コードの自動改善にも重要だ色々AIと検討したけど採用しなかった設計や、試したけどダメだったというAI対話コンテキストを、読みやすい章立てでテキストファイルに書き出すAgent Skill 記載するもの 目的や実装したものの挙動。ただしコード読めばわかる詳細は除外 実装しなかった別案とその理由 調査・設計・実装の中で言語化された、隠れた制約事項 あえて今回は対応しない事にした物事 注意が必要な難所 検討した事が実装者とAIの会話ログにしか残らないのはもったいない やった事はコード読めばわかる 検討した上でやらなかった事こそ、設計のレビューに必要な情報である AIで自動再調査できる

conversation-context-exportで書き出して、conversation-context-importで読み込むテキストファイルの事 対話コンテキストをテキストファイルにexport/importし、別のAI sessionに引き継ぐAgent Skill 最近はgithubのプルリクにコメントとして投稿する事が多いshokai.icon

OpenAIのAIコーディングエージェント https://chatgpt.com/codexwebで操作する既存のAIコーディングエージェントは開発タスク単体の作業にフォーカスしているのに対してCodexはタスク分割して、マネジメントするためのUIがある

pull requestのレビュー報告書を作成するAgent Skill bugや脆弱性の調査だけでなく、exportされたAI対話コンテキスト・pull request概要欄・実装されたコードの整合性を確認し、実装者の正気を疑う exportされた対話コンテキストを使ってpull requestを自動レビューするAgent Skillを実装したものshokai/agent-skillsからインストールできますshokai.icon責任共有・知識共有・正確さの向上など、元々コードレビューには複数の役割があったが コードと実装者とレビュアーという要素間に、AIというアクターが1つ増えた事により、より複雑になったこれまでのコードレビュー 以下の内容をレビュアーは自力で、もしくは1つずつプロンプトを入力する事で検証していた 何をなぜやってどうなったのか、を実装者は説明できているか pull request概要欄の品質チェック 説明と実装の整合性 実装者は、AIが作ったコードを読み解けているのか？ bugハンティング 実装にbugや脆弱性が含まれていないか？あるなら、続けて修正もしたい

指示に対して、チャットでの応答ではなく、作業計画書を返すモード Claude Codeで2025年6月ごろから導入された Codex CLIにも、2025年冬ごろには既に実装されていた承認すると作業を開始する コードを書く等承認したplanファイルはローカルマシンに残っている planファイルの置き場所整合性をとるべき複数箇所の変更作業、という単位でplanを作っているshokai.icon 関係し合うソースコードA, B, Cみたいなものでも、当然有効だが READMEで説明しているコンセプトと、機能の名称と、ソフトウェア上の関数の名前、みたいな組み合わせでも効く 説明と実装があってないぞ、とか気づいてくれる こういうのをplan modeを使わずに変更作業した場合 指示に従ってREADME書き換えて、流れ作業で関数の名前も置き換えるだけになってしまう 人間が雑に指示した、実装とは乖離した名前が関数につけられてしまう 作業計画書という形式で一旦書いてみる事によって、なんかおかしいな？と気づける。AIも人間も賢くなれる。

今日は休日。朝は６時前に自然と目が覚めた。せっかく早起きしたので、軽くストレッチをしてから近所の公園までジョギングに出かけた。新緑の季節で、空気がひんやりと気持ちいい。30分ほど走って汗をかいたら、頭がすっきりした。帰宅してシャワーを浴びた後、庭の花壇の手入れをした。先月植えたペチュニアが順調に咲いていて、雑草を抜きながら水をやる。土をいじっていると無心になれて、これはこれで瞑想みたいなものだなと思う。伸びすぎた枝を剪定して、肥料も少し追加しておいた。昼を軽く済ませてから、最近お気に入りのカフェに移動して読書。窓際の席でアイスコーヒーを飲みながら、積読になっていた小説をようやく半分ほど読み進めることができた。店内のBGMがちょうどよくて、気がつくと数時間経っていた。休日らしい休日。明日からの仕事もこの調子で乗り切りたい。

2026/2〜5の時点では、コードを完全に理解すべき状況は3つだと思っている plan mode + Codexに確認してもらい、単純なbugであれば修正してください。解決方法が複数ある場合は私に質問してくださいでだいぶまともな出力が得られる事がわかった為 今後また変わるだろう1. 機密情報を扱うもの 現状まだAIのセキュリティ関係の能力を信頼しきれないshokai.icon 何が機密情報かはアプリケーションやユーザー毎に違う ドメイン知識を完全にAIに注入できるか次第で、今後は変わる2. アルゴリズム・挙動・動作条件を人間に説明する必要があるもの 社内・社外の人間に説明する機会があるものは理解する必要がある 例：この機能ってIPアドレス制限でブロックされますよね？ → 開発者は営業同席の場で、確信を持って即答できなければいけない。不信に繋がる。 一般的な意味での説明責任3. その機能の上や隣に、機能を後から増築するもの

開発時に使っている便利なプロンプトshokai.icon解決方法が1つに定まるなら、修正までやるこれもcodex-consultationにより、確認が常人の確認ではなくなっている精度を左右する要素 modelの賢さ + 批判的思考の連鎖 AI対話コンテキストの密度 やらない事とその理由が明確になっているほど、1つに定まる

楽だからです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に「概要欄の説明とコードの実装に齟齬が無いか確認してください」と指示する

pull requestの概要欄を書きました。間違いや説明不足な点があれば指摘してくださいのバリエーション実コードを示しながら解説した方が良い物事は、レビューコメントに書くようにしているshokai.icon のでこっちの方が適切な場合がある 技術的な詳細 ちょっとしたtips 補足説明typoや説明不足な点が指摘されるvibe codingで起きがちな人間側の認識違いも指摘される 解説してもらうより、自分の解説を添削してもらう方が正しく理解できる わからない人が書く 複数の要素を総合的に見て、まとめて指摘してもらえる。AIへのレビュー観点だけでなく、人間向けの正しい概要欄が作れる。正気を疑う事ができる なぜpull request概要欄をAI使わず人力で書いているのか (shokai)

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

わからない事があれば実装前に私に質問してくださいよりも厳密な質問を求め、さらに自動的にClaude Codeにplan modeに切り替えさせるプロンプト 人間とAIの役割を入れ替えるやり方の1つplan modeに入る前に目的やコンセプトを語りかけ、調査し、曖昧な所を潰す為に使っているshokai.icon このプロンプトを使って質問攻めにあって、納得したら勝手にplan mode起動してもらうようにしています 曖昧な状態でplan作るとcontext浪費するから plan modeに入るべきタイミングは、AIの疑問がなくなった時だ 適切なタイミングを知っているのは人間ではなくAI なので、AIにコントロールしてもらいます

test page