最近はコーディングエージェントが自分の足りない部分を補ってくれるので、自分の強みをはっきり理解してそれを生かせれば、参入のハードルも下がるかもしれないと思っています。
私もいつもドキュメント化が課題だったのですが、それをコーディングエージェントにある程度委ねるようになって負担も減りましたし、さらにそのドキュメント化された資料を見直しているうちに、ドキュメント化に対する見る目も養われつつある気がします。

読んでいただきありがとうございます！以前はドキュメントやテストケース、検証など、人が直接気を配るべきことが多かったのですが、今ではかなりの部分をAIコーディングエージェントと一緒に進められるようになったので、思っていた以上にオープンソースも以前よりずっと運営の難易度が下がったように感じます！

@xguru リンクが間違っているようですね〜

そうですね、クリップボード履歴だけを見れば重なる部分は多いです。ただ、Raycast はクリップボードだけでなくほかの機能も多くて、少し過剰に感じていました。

私が気を配ったのはこういう点です。

まず軽量で、クリップボード履歴だけを管理するようにしています。現在は 2MB ほどですね。

そして保存した内容は詳細画面で編集して貼り付けられます。いくつものプロンプトを見直して事前に少しずつ手直ししたいときに便利でした。

検索とフォルダ分けにも気を配りました。仕事で必要な情報のうち、一度きりのものや、また探すのが面倒なものを解消できるように工夫しました。
本文、タグ、タイトルなどで検索できるようにしました。

将来的にはプラグインで機能や配置を直接追加できるようにしたいのですが、これはまだ具体化できていません。

Raycast も良いアプリだと思っていますし、好みに応じた選択肢になれるように頑張りたいと思っています。

ご意見ありがとうございます

こういうツールでいちばん難しいのは積み上げることではなく捨てることですが、garden を別のライフサイクルとして分離している点が目を引きます。

エージェントに与えるコンテキストは、古くなると単に役に立たないだけでなく有害です。人はドキュメントを見ると「これは昔の話っぽいな」と感じ取れますが、モデルにはその感覚がないので、3か月前に真だった不変条件を今も真であるかのようにそのまま受け取って使ってしまいます。コードならコンパイルが壊れたりもしますが、Wiki は静かに間違えます。

なので、ページにいつ時点の基準なのか、何を根拠に書かれたのかが付くのか気になります。Markdown でリポジトリに置いて Git でレビューさせるという選択はその点で正しいと思いますが、diff に残るのは文書が変わった時点であって、その内容がいまも有効な時点ではないので。

1,700件なら性能の話は実質ほとんど意味がない規模なので、フロントで直接処理してもバックエンドを置いても、どちらでも即座に表示されます。なので判断基準は速度ではなく、既存のPythonロジックを書き直すかどうかになるのが妥当だと思います。

その基準なら、いちばん合うのはStreamlitです。マッチングロジックをそのままimportして使えますし、画面もselectbox 5個と結果テーブルがあれば終わりなので、フロントコードを書く必要もありません。Streamlit Community Cloudに載せれば共有可能なリンクも無料で発行できますし、JSONをランタイムに読み込むようにしておけば、ファイルを差し替えるだけで最新データが反映されます。

静的HTMLはデプロイがより簡単な一方で、PythonロジックをJSへ移す必要があるため、スコア計算が少しでも複雑なら、その移植作業だけで数日が消えます。目標が今週中に動作を見せることなら、そのリスクは負わないほうがよさそうです。

ひとつだけ、Streamlitはどうしてもプロダクトというよりツールっぽく見えます。社内の意思決定者向けデモで、目的が「入力すれば実際に結果が出る」を確認することなら問題ありませんが、外部顧客向けのデモならその点は考慮したほうがよいです。

Raycast にある機能はほとんど対応しているようですが、何か違う点はあるのでしょうか？

おお… Show GN の投稿では、いつも「何か作った」を超えてこういうインサイトも一緒に見たいと思っていたので、そんな記事を読めて興奮します（笑）

案件ごとに専門家を探して業務範囲だけ任せるより、一人に渡せば勝手に全部うまく処理してくれることを望むのが人間の心理ではありますよね
LLMも、何でも適当に投げれば全部受け止めてくれるような形で報酬関数が組まれざるを得ないのではないでしょうか

公開ベンチマークとはいえ、ここまで具体的な数字は初めて見ました。ありがとうございます。

159件 / 76件 / 3,197件という比率が特に目に留まりました。判定不能（IDなし）が圧倒的に多いということは――結局、重複の大半が追跡そのものができない領域にあるという意味で、「監査ログがあれば大丈夫」と安心してはいけないことを改めて確認しました。

生成（POST）を優先するという方針は、私たちの設計とまさに一致しています。私たちの hash chain で idempotency key を生成イベントにまず付けようとしていた理由が、まさにここにありました。

メールの message ID の提案はすぐ反映します。内部ツールの仕様に「レスポンスにエンティティ ID を必須」と追加するだけで、監査ログの検証可能性が変わるのだと分かりました。hash chain に ID をアンカーとして使えば、重複の有無を計算だけで確認できますし。

ちなみに、3,197件の「IDなし」ケースがどのツール種別に偏っていたかは把握されていますか？ メール以外に「成功/失敗」だけを返すツールがどれくらいあるのか気になります。

現在は最適化中なので、今週中に完了すれば、よりすっきりご覧いただけると思います :)

もう韓国語切り替え機能を追加してくださったんですね :)
本当にありがとうございます

私も似たものを作っている方に会えて、かなりうれしい気持ちです！

私は大Claude時代が来る前から、RustでAPIも作りCLIも作りしながら、Rustにかなり多くの時間を投資していました！

tmuxを置き換えるべきだと考えたのもかなり最近で、tmux自体を置き換えてからはまだそれほど経っていませんが、マルチプレクサも作って、2日目からtmuxの使用を最小化していました！
ここでは完成度だけでなく、自分が作ったツールではない別のツールへのフォールバックがあると、むしろそれが逃げ場になって開発をあまり頑張らなくなる面も大きかったのではないかと思います。

そして4か月という時間がかかったのは、おっしゃっていたように、自分好みの機能を複数の人が使える形へ拡張可能にするのにも長い時間がかかった気がしますし、これを一般公開しようとすること自体にもかなり勇気が必要だったからではないかと思います。

それから、orcaのようなプログラムは企業の支援を受けている一方で、個人的に進めるプロジェクトのモチベーションについては、私はむしろ前向きに考えています。
もちろん、金銭的な負担が生じることほど大きな動機付けもないでしょうが、私はすべてのワークフローを自分が使うツールに合わせてあるので、今すぐ自分が仕事をするにもこのツールを改善しなければならない立場で、個人の時間もできるだけ切り詰めてこれらのツールの改善に投資しています。
もちろん、自分のモチベーションが落ちた瞬間に終わってしまう問題はありますが、その状況を防ぐために、意図的に自分のワークフローを自分のツールに最適化して、そうした状況を防ごうとしています！
個人的には、今この瞬間でも競合ツールに比べて足りないのは技術的なことではなくマーケティングだけだと思っていて、フィードバックを受けてみようと公開したこと自体もかなり大きかった気がします。

GPUレンダリングを行ったのは、Windows対応のためというより、技術的な挑戦と、ターミナル画面をいっぱいに使うプログラムに対する最適化のためでした。
個人的にWindowsを開発用途で使わなくなって久しいので、そのOSへの対応は深く考えられていなかったのですが、今は土台がかなりできてきた気がするので、一度挑戦してみる価値はあるかもしれないですね。

私の目標は、開発全般がcopadひとつで完結することですし、そのためにpluginシステムも作ってあります！
なので、GUIが必要な機能もできるだけcopadに実装しようとしています。

レンダリング方式にはかなり大きな違いがあるのですが、実際のところエンドユーザーの立場で体感できるほどの差ではないので、詳しく紹介するのは少し気恥ずかしいですね。おっしゃるように、生産コストが下がるにつれて、手になじむものが一番という世の中になったのではないかと思います……！

社内の相談記録を人事部の懲戒フォルダに集めていたサムスンは、やはりグローバルな先導企業ですね

実サービスへの適用はまだ試せていません。これらの数字はすべて公開ベンチマークのトレースから出たものなので、まずその限界をお伝えするのが適切だと思います。

ただし、idempotency key の設計の参考になりそうな観測が1つあります。

「呼び出しが2回」vs「実行が2回」を区別してみようと、応答に含まれるエンティティ ID を比較してみました。同じ引数で2回呼び出されたときに応答 ID が違えば実際に2つ作られたということですし、同じなら API が自動で弾いてくれたということです。

Toolathlon ベンチマーク基準で、状態変更ツールの重複呼び出しのうち:

ID が異なっていたもの（実際の重複生成）: 159件
ID が同じだったもの（API が dedup）: 76件
ID 自体がなく判定不可: 3,197件

ここで1つ構造が見えました。ID が異なっていた159件は、すべて作成系ツールでした（ドキュメント作成、スプレッドシート作成、ファイルアップロード、クイズ作成）。一方、更新系（patch、update、enroll）では ID が異なる事例が1件もありませんでした。同じ対象を指していたため、新規作成にはならなかったということです。

つまり idempotency key を付けるなら、作成（POST）側が優先順位になりそうです。更新側は、すでに自然に冪等になっている場合が多く見えました。

そして先ほど申し上げたメールの問題が、ここでもまた引っかかります。メール送信は応答が「成功」という文字列だけなので、ID 比較ができませんでした。idempotency key を付けても、それが実際に機能したのかはトレースだけでは確認する方法がありません。内部ツールを設計されるなら、送信結果で message ID を返すようにするだけでも監査ログで検証できます。おっしゃっていた hash chain 方式とも相性がよさそうです。

あらためて限界を申し上げると、上の数字はすべてベンチマークのトレースなので、実際の運用環境でも同じ比率になるかは分かりません。もしトレースを回してみる機会があれば、結果がどう違うのか気になります。

スクリーンショットを入れておくかごみたいですね。

似たような発想のJITコンパイルのアプローチとしてnumbaがありますが、こちらのほうがカバレッジが広い印象ですね。

GPT OSS 120B のようなものを出しさえすれば、それなりに説得力がありそうですが、どうでしょうね。

では、クローズドなLLMをできるだけ安価に市場へ供給するのが最善ということになります。高性能な知能へのアクセス性が高まれば、自然とオープンウェイトモデルを開発する動機は弱まり、技術的リーダーシップも一般の機関が持てるはずです。なのに当のAnthropicは、市場でいちばん排他的な供給者ですよね？