更新テストshokai.icon (2023/4/6 20:21)リンクパスワードつきgyazo private projectの画像 更新通知テスト

Claude Code on the webでどのリポジトリに対して作業している場合も、いきなりCosense Skill & CLIが使えるようにする方法を解説しますshokai.iconクラウドコンテナを作る https://claude.ai/code から新規チャットを開き、入力欄の上の雲のアイコンから作成 作るのはクラウドコンテナなのだが、この画面では「クラウド環境」という名称になっている 初回はGitHubの接続を求められるため、接続を行う クラウド環境の設定 ネットワークアクセス 「カスタム」でscrapbox.ioを追加 開発しないならこれでよい。WebFetch toolはこのネットワークアクセスの制限を受けない もしくは「Full」 開発するので私はこっちshokai.icon curlコマンドやnode.jsからネットワークアクセスできる 環境変数 環境変数COSENSE_PATに自分のCosense Personal Access Tokenを設定する

AnthropicのClaudeをwebで使えるAIチャットサービス https://claude.ai 実行環境はクラウド側にある

https://claude.ai の方から、コネクタとしてSlackを追加・設定・有効化しておく するとClaude Code on the webでもslackコネクタが使えるようになる どういう事か？ https://claude.ai/code の方にはコネクタをインストールする画面があるが、設定ボタンが出てこない claude.aiの方で設定すると、Helpfeelのslackが読めるようになる

https://claude.ai/code で使えるClaude Code リサーチプレビュー段階である料金 AIトークンコストしかかからない 割増されたりもしない CPUもネットワークも無料 とはいえ、さすがにビットコイン採掘とかしたらBANされると思うクラウドコンテナというLinux VMがchat毎に付いている

AIのためのCosenseのUIとしてのCLIと、それを人間が扱えるようにする為のAgent Skillnpmレジストリ https://www.npmjs.com/package/@helpfeel/cosense-cliリリースリポジトリ https://github.com/helpfeel/cosense-cli

Claude Code on the webはクラウド側で動くchatとクラウドコンテナ（LinuxのVM環境）のセットである コンテナ内にCosense Skill & CLIをセットアップできる セットアップ済みのVMを、Helpfeel社内で使える環境として配ろうかshokai.iconと思ったが、設定がややこしすぎてあきらめたややこしいポイント Skillのセットアップ Server-managed settingsとして書き、org全体に配る これ以外にskillを最初からインストールさせる方法は無い CLIのセットアップ セットアップスクリプトを書く VM起動時に実行される VMは起動から約1週間キャッシュされ、スナップショットから起動する この方法だと、on the webではない、org内全員のローカルマシンのclaude codeにSkillがインストールされてしまう しかもCLIはインストールされない。CLIなしでSkillだけが強制インストールされる。最悪だshokai.icon

株式会社HelpfeelでCosenseを開発しています shokai.icon*6 橋本翔 http://shokai.org https://github.com/shokai https://twitter.com/shokai SW-0404-5900-0238#人物ここからUserScript code:script.js console.log('initialize user script');

#レシピ見た目に反して簡単に作れてよい。しかもうまい材料 丸鶏 イオン系スーパーでたまに値引きされて1000円ぐらいで売ってる事がある。即確保 S&B等のスパイスミックス 「鶏の香草焼き」みたいなやつ 150円ぐらい 1パッケージに2回ぶん入っている オリーブオイル ビニール手袋 タコ糸 縛れてヘルシオで燃えなければ何でも良い手順

じゃがいも入れるのはアリクミン合う

#料理 #レシピ材料 豚バラ肉 200g 食べやすい大きさに切る じゃがいも 4個 大きめの乱切り 人参 1本 乱切り 玉ねぎ 1個 くし切り だし 醤油 みりん 料理酒 砂糖 大さじ1〜2 ごま油手順

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とあまり変わらないんじゃないか？という感触がある。なんとなく。 富豪的で非同期な挙動の戦略が、賢さの秘訣なのではないか？ 7/2に復活したやつでは、そんなにかからなくなった。Ask Question Toolが60秒で推奨選択肢で仮確定されるようになったから1を聞いて10を知るような挙動をしている

Claude Codeが生成するUI「AskQuestionToolください」または「選択UIください」で確定出現させれるshokai.icon選択肢に回答できない時の原因は自分にある vibe codingで作った物の上に後から増築した事によって回答できなくなった場合は、見積もりが甘かったと反省すればいい プロダクト・仕様・既存コードベースへの理解が足りない状態 単に自分の限界を超えた作業をやっている場合 それを実感できるのはうれしい。勉強チャンス！！！

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

飢餓感を失わせてリリース力を下げるし、品質が上がらない原因になる事もあるからshokai.icon以下は昔/Nota/なぜScrapboxにはstaff featureフラグが無いのかに書いたページ。プロダクト名も社名も今は違うけどあえて修正せずそのまま転載しておくscrapboxにはstaff限定フラグが無い 全ての新機能はNota社員と全scrapboxユーザーに同時に配信されるstaff featureがあるとリリース力が落ちると思っているshokai.icon 新しい機能を実装する時に最も力が必要な瞬間は2つ 作り始め scrapboxにアイデア書き溜めてやる気を出すテクニックを使う あとはemacsとdockerをすぐ起動できるMacがあれば、乗り越えれる 作り切る クオリティを80点ぐらいから仕上げるのが大変 細かい挙動・見た目・例外処理の調整など Tatamiや、すぐ使えるFont Awesome等のassetsはかなり助けになる shokai.iconは、作り切るフェーズを乗り越えるために飢餓感を利用している この素晴らしい機能が目の前にあり、今すぐ俺は使いたい

/Nota/骨を拾う活動から昔書いたページをコピペプロトタイプを作っても、サービス本体に組み込まない事の方が多い これは当然 プロトタイプを全てサービス本体に組み込むとキメラになる作ったプロトタイプがダメだった時、何がどうダメだったのかの振り返りを行いましょうshokai.icon 経験と反省を持ち帰る ダメな物と理由のリストができて、次回以降の意思決定が消去法で高速化する ダメだという事がわかった、という発見だと考える やらない事とその理由として再利用できる 振り返らない場合、ただ「ダメだったなあ」でつらいまま終わってしまう 全体としてはダメだけど、たとえば表現方法とか、部分的には良い部分もあるかもしれない ターゲットや打ち出し方を変えれば良いかもしれないPull Requestの概要欄に「これは何を解決するどういう物なのか」をきちんと書いて、その上でダメな理由も書いて、closeしましょう

/Nota/試作の持ち込み方相談から抜き書き 個人活動で、あるいは業務でプロトタイプを作ったが、その後の行動についての悩み・試みを話していた 自分が書いた部分だけ抜き出すshokai.icon「作ってみた」で終わらずに、必要性を説明し、計画を発表して、進めれば良いのではないかshokai.icon 必要性 誰が困っているのか あるいはこれがどう世の中を変えるか 人類はどうあるべきか 既存のものは何がダメなのか 既存のものが存在しない場合は、理由を考える 計画 こういうのをこうやってリリースします 今割り振られている役割・タスクをこなしつつやる あるいは、これをやるべきだから、今割り振られているタスク・役割は返上します、と交渉する で、とてつもない反論が出なければ進めれば良い

https://corp.helpfeel.com2022年10月、NotaからHelpfeelに社名を変更した京都にあるGyazo、Helpfeel、Cosenseなどを作っている会社shokai.iconは品川からリモートで働いている

2つの機能があり、それぞれ個別には正常に動いている しかし矛盾が生じる場合がある 例えば、ページmerge alertと被リンク置換alertが同時に出てしまう問題だから機能を減らそうshokai.icon 自分が使わない機能を実装するのをやめよう 既にある機能も、使わないなら削ろう 機能が少なければbugは減る 1度bugを見たユーザーは全てが疑わしくなる 正常に動いている機能であっても、怪しいと思ってしまう 開発者が使わない機能を付けると質が下がるshokai.iconが暗黙的でユーザー側にルールが見えづらい機能を「おせっかい」だと言うのはこの為です 疑心暗鬼を呼んでしまう

要望きた！→即実装！をするとクソアプリになる その機能がユーザーが望まれていて、自分も欲しいと思っていたとしても、すぐに機能として組み込まない方が良い当初ここに「これは詭弁だけど〜」と書いていたけど、実際には本気でそう思っていますshokai.iconリモートワークでは焦りがオーバーワークを産み、判断を誤らせる いつでもどこでも無限に仕事できてしまうし、深夜でも何でも対応できてしまう 速度が上がっていくとハイになりすぎて、わからなくなる ただの思いつきなのか 本当に必要な機能なのか 以前/remoteというイベントで話した事の中から、ブレーキをかける事に自分で自分を納得させる為の考えをまとめる リモートワークについての知見を話してきた機能をどんどん追加しちゃだめ

/Nota/新機能の最初のリリースを早くする方法からほぼコピペ最初のリリースを早くする技を解説しました。1時間ぐらい喋ったshokai.icon コンセプト分割して段階的実装を計画しろ proof of conectすべき核ギリギリまで削ってさっさとドッグフーディング開始しろ 重要ではない所は手を抜け 詳細は下を読んで下さいプロダクトをどこからどう作るのが良いか考える会 シリーズ第1回 2024/12/3(火) 17:00〜18:00 今回掘り下げる話題はここ 2. プロトタイピングと最初のリリース とにかく無から形にするのが求められる かつ、ものによっては性能改善や機能の余白を残しておく さっさとリリースする 実際に使ってみて、その機能のスジが良いか感触を確かめるため ここの精度を上げると、1の領域にも少し入ってこれるようになるはず

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

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

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

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を使った開発フロー