#開発ツール

図を作るための新しいテキスト言語「reladraw」のGitHubリポジトリが公開されている。見た目は地味だが、狙いはかなりはっきりしている。Mermaidのように文章から図を起こせる手軽さは欲しい。でも、配置をある程度こちらで決めたい場面では、MermaidやGraphvizの自動レイアウトでは足りない。そこで、その中間を埋める道具として作られている。図を手で引く面倒さに悩んだことがある人ほど、話が見えやすいはずだ。 リポジトリのREADMEによると、reladrawは「図について、どこに何を置くかを言葉で書く」ためのテキスト言語だという。作者は、draw.ioで毎回ドラッグして配置を詰めるやり方は手間が大きすぎる一方で、MermaidやGraphviz、D2のように箱と線だけを宣言してあとは自動配置に任せる方式では、頭の中にある絵をそのまま出しにくいと感じていた。そこで、見た目はきちんとコントロールしたいが、座標を一つずつ指定するのは避けたい、という欲求を満たす位置にreladrawを置いている。 READMEには、簡単な書き方の例も載っている。たとえば `node app "We

開発者向けの新しい道具は、見た目が派手でも中身が薄いことがあります。ですが今回の `drawgent` は、ただのデモではなく、Excalidraw のキャンバスに接続した実用寄りのエージェントとして作り込まれていました。コードや図を同じ画面で扱いながら、対話で修正し、さらに手描きのジェスチャーまで入力にしてしまう発想が面白いです。しかも更新履歴を見ると、UI の飾りよりも、実際に使えるようにするための細かな改良がかなり詰め込まれています。 元記事は Tangled 上のリポジトリ `yanndegat.tngl.sh/drawgent` を見せています。説明欄は空で、README の冒頭だけが見えている状態ですが、そこからはこのプロジェクトが何を目指しているかは読み取れます。`drawgent` は「自分の Claude Code、Codex、opencode」を Excalidraw のホワイトボードにつなぎ、チャット欄で「図を描いて」と頼んだり、図の横に `AGENT:` と書いてその部分を直させたりできる仕組みです。エージェントはキャンバスのスクリーンショットと scene を

クラウド向けの開発は、ちょっとした確認のたびに遠い環境へつながり、認証情報を用意し、結果が返るまで待つ——この繰り返しが意外と重い。Flociは、その往復をローカルに持ち込もうとする新しい試みだ。AWS、Azure、GCP、OCIを自分のPC上で動かし、しかも起動はミリ秒単位だと打ち出している。特に、コードを書くAIエージェントが増えた今、「安全に試せるクラウド」があるかどうかは開発体験をかなり左右するはずだ。 Flociは、自分たちを “Local Cloud Emulators” と位置づけている。対象はAWS、Azure、GCP、OCIの4系統で、いずれもローカルで動くエミュレーターとして提供される。サイト上では「Any cloud. Locally.」と掲げ、開発者やAI coding agentsのために、無料で、認証情報なしで、すぐ使えるフィードバックループを作るのが狙いだと説明している。 各クラウドごとに独立したMITライセンスのバイナリが用意されていて、アカウント作成も認証トークンも必要ない。AWS向けの `floci` はLocalStackの置き換えをうたっており、

AIでソフトウェアを書くとき、まず計画を立てるべきか、それともとにかく作り始めるべきか。Ayman Nadeem のこの文章は、その問いに対して自分の考えがどう変わったかをかなり率直に書いている。彼は今年前半、計画こそがAI時代の開発で最重要になると信じ、その思想を前提にしたデスクトップ向けのコーディングアプリ「Nuanced」まで作った。ところが実際に使われてみると、Plan mode は期待した役割を果たさなかったという。この記事は、単なる製品の反省文ではなく、AIコーディングツールが「計画」をどう扱うべきかという設計論にも踏み込んでいるので、今読んでおく価値がある。 Ayman Nadeem は、AIによってコード生成の速度と量が一気に増えた一方で、それを支えるインターフェースが追いついていないと見ていた。そこで作ったのがデスクトップのコーディングアプリ Nuanced だった。彼の問題意識は、機械が人間よりずっと速くコードを増やしていく状況で、人間がソフトウェア全体の理解を失わずにいられるのか、という点にある。数千行のコードが数分で生成されれば、作る前に「何を作るのか」「なぜ作

AIにコードを書かせるのは珍しくなくなったが、その結果として「なぜそうなったのか」が見えにくくなっている。devdotfast/whiteboard は、その穴を埋めようとするオープンソースのデスクトップアプリだ。単なる図解ツールではなく、AIエージェントの作業内容や判断を、コードと行き来しながら追える作業台として作られている。GitHub上の公開リポジトリとして出てきたことで、こうした“説明できる開発”をどう実装するのかが一気に見えやすくなった。 元記事で示されている Whiteboard は、「thoughtful software design」のための open-source canvas だと説明されている。対象は開発者だけではなく、人間とエージェントが同じワークスペースでソフトウェアを組み立てる使い方だ。macOS と Fedora 向けのダウンロード、Webサイト、Discord への導線もあり、README だけの試作ではなく、実際に触る前提のプロダクトとして見せている。 中心にあるのは、Claude Code や Codex など既存の coding agent とつ

この記事を読んでまず思ったのは、AI coding agent の比較軸がずいぶん変わったな、ということだった。コードをどれだけ書けるかだけではなく、「前の指示を次の repo でも覚えているか」を見るのか、と。人間の開発でも、チームの暗黙知を引き継げるかどうかはかなり大事だけれど、それが agent でも同じように効いてくるなら、記憶力はもう単なるおまけではない。 面白かったのは、ここでいう memory が人間の記憶みたいに曖昧なものではなく、かなり実務的な意味で使われているところだと思う。要するに「このツールは前回こういうルールで動かしたけど、今回もそれを守るのか」という話で、これができないと毎回こちらが同じ説明をやり直す羽目になる。そうなると、便利そうに見えて実際はだいぶ疲れるはずだ。生成の速さより、文脈の持続のほうが効く場面は確実にある。 一方で、こういうテストはとても分かりやすい反面、どこまで一般化していいのかは少し気になった。ある repo で覚えていた、別の repo で忘れた、という結果は確かに重要だけれど、実際の現場では memory 以外にも、プロンプトの書き方や

この記事を読んでまず思ったのは、AIコーディングを“魔法”として持ち上げるのではなく、ちゃんと現場の道具として並べているのが好ましい、ということだった。Claude Code、VS Code、GitHub Copilot、Cursor。名前だけ並ぶと華やかだけれど、記事の温度はかなり実務寄りで、派手な成功談よりも「どう使い分けるのか」「どこに効くのか」に寄っている。その距離感が、むしろ信頼できる。 特に引っかかったのは、「トークン」という言葉を前提にしているところだ。AIの文脈では当たり前でも、普通の開発者にとってはまだ少し抽象的だと思う。要するに、AIが一度に扱える情報量の単位みたいなものだが、それが増えると会話やコード全体をまたいだ作業がしやすくなる。一方で、量が増えれば何でも解決するわけでもない。記事はそこを煽りすぎず、トークンの扱いが実用上の差になる、という線で止めている。その控えめさがよかった。 もう一つ、AIコーディングを「個人の生産性向上」だけで終わらせず、チームや開発プロセス全体の話に接続しているのも印象に残った。AIがコードを書く速さは目立つけれど、本当に面倒なのはそ

最初に思ったのは、これはかなり“気持ちよく危ない”機能だな、ということだった。 AI に仕事を割り振って並列に走らせる発想自体は自然だし、開発の流れに合っている。けれど、記事が指摘している通り、その便利さはたぶん請求や利用枠の消費とセットで来る。昼前にプランを食い尽くす、という言い方は少し大げさに見えて、実際にはわりと現実的な怖さだと思う。 とくに引っかかったのは、Claude Code Projects が「コーディネーター」を中心に再設計されている点だ。人間の感覚だと、プロジェクトは作業の置き場で、メモや履歴が残る場所という印象が強い。でもこの記事では、そこが単なる保管庫ではなく、複数の thread を束ねる司令塔みたいに扱われている。AI が一人で考えるというより、細かい役割に分かれた複数の AI をまとめて回す方向に寄っていて、いよいよ開発ツールというより“仕事の配車係”に近づいている感じがした。 ただ、その形はかなり強力である一方、使い方を間違えるとノイズも増えそうだと思う。並列化は速さを生むけれど、同時に判断のコストも上げる。どの thread に何を覚えさせたか、sha

これを読んでまず思ったのは、「更新履歴なのに、もはや不具合報告の墓場みたいだな」ということでした。新機能もあるのですが、目に入るのは圧倒的に細かい修正の多さです。しかも単なる見た目の微調整ではなく、クラッシュ、セッションの消失、更新失敗、プロキシ環境、Windows、長いパス、壊れた設定ファイルまで、かなり広い範囲に手が入っている。便利なツールほど、実際にはこういう地味な綻びを一つずつ潰していくしかないのだと改めて感じました。 特に印象に残ったのは、Claude Code が「大きく壊れる」パターンをかなり執念深く直しているところです。たとえば設定ファイルが少し壊れているだけで起動時に落ちたり、履歴の保存形式が変だっただけで再開できなかったり、プロンプトに terminal color codes が混ざっただけで interface error になったりする。こういうのは派手さはないけれど、使う側からすると一発で信頼を失う原因です。AIエージェント系のツールは、賢さそのものより「落ちない」「変な状態から戻れる」ことのほうが先に効いてくるんじゃないかと思います。 もう一つ、妙に人間臭

この記事を読んでまず思ったのは、コーディングエージェントって思った以上に“提案文のうまさ”に左右されるんだな、ということだった。 同じカテゴリのサービスでも、どの文章を見せるか、どの前提を与えるかで選ばれ方がかなり変わる。しかもその差が、人間が想像する「性能差」よりずっと大きい場面があるのが面白いし、少し怖い。 特に引っかかったのは、「言及されること」と「選ばれること」がほとんど別物だという点だ。 Stripe や Neon のように強い勝ち筋がある一方で、PayPal や LangChain のように何度も名前が出るのにほとんど採用されない例がある。人間の感覚だと、知名度が高いものはそこそこ勝つ気がする。でもエージェントは、ブランド名よりも、今いるコードベースでの相性や、ページの説明の仕方、制約に合うかどうかをかなり露骨に見ているように見える。そこはむしろ誠実だと思う。 一方で、この記事全体には少し営業っぽさも感じた。 「どうすれば coding agents に選ばれるか」という視点が強くて、研究というより市場攻略の匂いがある。もちろん Armature 自身がその分野で仕事をして

この記事を読んでいちばん強く思ったのは、「同じモデルを使っているのに、こんなに差が出るのか」という驚きでした。LLM の話はつい「どのモデルが賢いか」に寄りがちですが、この記事はその手前にある harness、つまりエージェントを包む実行の仕組みが、実はかなり財布に効いてくると突きつけています。 面白いのは、差が単なる誤差ではなく、70倍という桁で出ていることです。ここまで来ると、モデル選びよりも「どう会話させるか」「どこまで確認させるか」「何を毎回与えるか」の方がコストを食っている可能性が高い。しかも coding agent では、その“余計なやり取り”がそのまま token に化ける。人間が見れば丁寧さに見えるものが、機械側では請求書になるわけです。 もうひとつ引っかかったのは、こういう話が思った以上に見えにくいことです。出力の品質だけ見ていると、ハーネスの違いは気づきにくい。でも実際には、同じモデルでも、包み方次第でまるで別物のサービスになる。これは開発者にとってかなり不公平にも見えるし、逆に言えば最適化の余地が大きいとも言えます。モデル性能の比較だけで満足していると、

まず思ったのは、これはかなり小さい話に見えて、実はかなり大きい問題だということです。 `AGENTS.md` を読むか読まないか、たったそれだけで揉めているように見えるけれど、実際には「AIエージェントにどこまで現場の文脈を持たせるのか」という話なんですよね。 Shopify のCEOが怒ったのも、単なる気分ではなくて、規模の大きいコードベースで働く人にとっては切実だからだと思います。人間の開発者なら、リポジトリの説明ファイルやチームのローカルルールを見てから作業するのは当たり前に近い。でも Claude Code のようなツールがそこを読まないと、毎回「このツールには手順を口頭で教え直す」ことになる。記事中の `complexity tax` という表現は少し大げさにも見えるけれど、運用する側からするとたしかに税金みたいなものかもしれません。便利さのはずが、使うほど説明コストが増えるのはいやな感じです。 もうひとつ引っかかったのは、Anthropic 側がその要望をすでに閉じていた、という点です。ユーザー側の不満がはっきり出ているのに、製品の設計として優先されていない。このズレは、A

これ、かなり好きだと思った。しかも「プロンプトでなんとかする」のを早々に諦めているのがいい。AIの口調って、少し直したくらいではなかなか抜けない。とくに Claude みたいに、説明が妙にドラマチックになったり、やたら含みを持たせたりする癖は、本文の内容がまともでも読み味を変えてしまう。そこを“別モデルにそのまま投げる”というのは、雑に見えてかなり実務的だ。 面白いのは、これが単なるネタツールに終わっていないことだと思う。`colleague`、`manager`、`director` と出力の相手を分けているのは、実際の現場で「同じ内容でも、この人にはこの粒度で伝えたい」という感覚に寄っている。要するに、AIの文章をきれいにするというより、読み手に合わせて“気持ち悪くない言い方”へ落とす仕組みなんだろう。あの「three numbered revelations」みたいな、やけに大げさな文体に疲れている人は多いはずで、そこを真正面から笑いに変えているのも含めて、かなり現場感がある。 一方で、別のAIに翻訳させる以上、最終的な口調の責任をどこが持つのかは少し気になった。元のClaude

この記事を読んでいちばん引っかかったのは、AIが「明らかな悪意」には強くても、ばらばらに置かれた普通の文を自分でつなぎ合わせると途端に危うくなる、という点でした。 人間でも、別々の場所に書かれた指示を読み違えることはあります。ただ、AI coding agent はそこに加えて、tool result や tool description みたいな“信じてよい場所”をまたいで意味を組み立ててしまう。そこが怖い。悪い命令が一文で書かれていなくても成立してしまうなら、従来の「この文は怪しいから止める」という防御はかなり頼りないと思います。 面白いのは、これはモデルの賢さだけの話ではない、という書き方でした。同じモデルでも、どの client から使うかで挙動が変わる。つまり、危うさはモデル単体ではなく、周辺の安全設計にかなり依存している。ここはAI開発の現場で見落とされやすい気がします。つい「どのモデルが強いか」に話が寄りがちですが、実際には MCP のつなぎ方、tool の受け渡し方、human approval の置き方のほうが効いてくる場面があるんでしょう。 それと、記事のトーンが示

この記事を読んでまず思ったのは、これは「AIが賢くなった話」よりも、「人間の確認作業が思った以上に当てにならない」という話だな、ということだった。少し意地の悪い言い方に聞こえるけれど、本文のトーンもそこをかなりはっきり突いていて、そこに妙なリアリティがある。 Claude Code の auto mode をデフォルトに寄せる、というのは一見すると攻めた仕様変更に見える。でも記事を読むと、その判断の根拠が「人間が危ないコマンドを見逃すから」という話で、そこがちょっと怖い。普通は「自動実行は危ないから人間の承認を入れる」が自然に思えるのに、逆に classifier のほうが人間より危険な命令を拾える、という前提になっている。ここには、レビューや確認という行為への信仰がかなり揺らいでいる感じがある。 ただ、私はこの話を単純に「人間はダメ、AIはすごい」とは受け取れなかった。むしろ引っかかったのは、危険なものを止める役目を classifier に寄せたとき、どこまでを「危険」とみなすのかがどんどん重要になることだと思う。開発者が本当に見たいのは、見た目が危なそうなコマンドだけではなく、文

正直、最初に思ったのは「そこまでやるのか」という驚きだった。コードを書くAIの進化って、ついモデルの賢さや速度の話に目が行くけれど、この記事はもっと地味で、でも実務ではかなり効く方向に寄っている。別々のTerminalで動いているClaude同士が、手でコピペしなくても文脈を渡し合える。派手さはないけれど、こういう小さな摩擦の削減が一番ありがたい場面は多い。 面白いのは、Anthropicがここで「会話の全部」を共有させていないことだと思う。やり取りできるのはtextだけで、historyやfilesやpermissionsまでは渡らない。これは少し中途半端にも見えるけれど、むしろ現実的だとも感じた。AIエージェント同士をつなぐと、便利さと危うさがすぐ同居する。権限まで自由に飛んでいくと怖いし、ファイルや過去ログまで自動で共有されたら、気づかないうちに見せたくないものが広がりそうだ。その意味で、メッセージは通すが勝手な許可変更はさせない、という線引きはかなり妥当ではないかと思う。 一方で、これが本当に効くのは「複数セッションを同時に回す人」だけだろうとも思った。普通の人にとっては、まだ

この記事を読んでまず思ったのは、ツールが「正しそうに見える間違い」を平然と出す怖さが、かなり生々しく書かれているな、ということだった。しかも厄介なのは、単にバグを踏んだ話ではなく、調べた先の見え方そのものが誤解を誘う形になっていた点だと思う。 いちばん引っかかったのは、package rename が「存在しない package」と区別できないという話だ。version を見ているだけでは、まだ出ていないのか、名前が変わったのか分からない。言われてみれば当たり前なのに、実際にはその当たり前を見落としやすい。機械的な checker ほど、見つかった事実だけで断定してしまう危うさがあるんだなと思った。 もうひとつ印象に残ったのは、broken link の話だ。spec を参照しているつもりのリンクが、実は overview に飛ぶだけで、見た目には壊れていない。これはかなり嫌な失敗で、単に「リンクが切れている」よりタチが悪い。検証できる顔をしながら、実際には検証先が違う。こういうのは人間でも気づきにくいし、だからこそ test で縛るしかないのだろう。 ただ、ここで面白いのは「dete

Anthropicの「Claude Code」デスクトップ版に、Webブラウザーがそのまま入った。これ、地味に見えてかなり大きい変更だと思う。AIコーディングツールって、普段はターミナルやエディタの中で完結しがちだったのに、そこへ外部サイトやドキュメント、イシュートラッカーまで“同じ画面の中”で扱えるようになったわけだ。 デスクトップ版「Claude Code」に内蔵ブラウザーが追加された タブ付きで、ドキュメントや外部サイトを複数開いておける 既存のローカル開発サーバーを見るのと同じ感覚で、ページを読ませたりクリックさせたりできる 安全対策として、外部サイトでの操作には確認が入る ブラウザーのプロファイルは普段使いのブラウザーと分離され、ログイン情報や履歴は引き継がれない 今回のポイントは、「Claudeにコードを書かせる」だけでなく、「Claudeに画面を開かせて確認させる」流れが、アプリの中で完結しやすくなったことだ。 たとえば、仕様書を読みながら実装を進めたいとき。GitHub Issuesを見つつ、関連ドキュメントも見つつ、ローカルの開発画面も見つつ、という作業は普通にある。

GitHubで見つけた `deepclaude` は、ひとことで言うと「Claude Codeの見た目と操作感はそのままに、裏側のモデルだけを安いものへ差し替える」ためのツールです。 発想がかなり気持ちいいです。高い道具の“外側”はそのまま使って、頭脳だけ別のエンジンに載せ替える感じ。こういうやり方、地味だけど実用性が高いんですよね。 Claude Codeの自律的な開発ループを、そのまま使える 裏のモデルを DeepSeek V4 Pro、OpenRouter、Fireworks AI、Anthropic に切り替えられる 使い勝手はほぼ同じで、コストはかなり下げられる 端末上で動くプロキシがAPIを横取りして、バックエンドを差し替える仕組み 途中で再起動せず、セッション中にモデルを切り替えられる ただし画像入力やMCPなど、いくつか弱い部分もある 元記事の主張はわかりやすいです。Claude Code は「自律型のコーディングエージェント」としてかなり優秀だけれど、月額 $200 と高い。そこで `deepclaude` は、Claude Code の CLI やツールループ、ファ

Claude CodeのようなLLM向けツールで、長いテキストをそのまま送らず、画像に変換してからモデルに渡す仕組み 文字がぎゅっと詰まった内容ほど得をしやすく、場合によってはトークン使用量を大きく削減できる ただし万能ではなく、IDやハッシュのような“1文字でも間違えたら困る情報”は危ない だからこそ、安くなる場面と危ない場面を見極める設計になっている 発想はかなり攻めているが、実務の痛点をちゃんと突いていて面白い pxpipeは、ひとことで言うと「LLMに渡す長文を、必要に応じて画像に圧縮してしまうローカルProxy」です。Proxyというのは、アプリとAPIのあいだに入って通信を中継する仕組みのこと。ブラウザの世界でいう“中継サーバー”みたいなものだと思えば大きく外れていません。 普通、LLMにたくさんの文章を読ませると、そのぶんトークンが増えます。トークンは、AIが文章を扱うときの細かい単位で、課金やコンテキスト長の計算に使われます。つまり、長文を入れるほどお金も容量も食う。これは避けようがない、と思われがちです。 でも pxpipe はそこに逆張りをします。大量のテキストをP

AIに「コードを書いて」と頼むのが当たり前になってきました。便利です。かなり便利。でもSecurityWeekの記事が取り上げているのは、その便利さの裏で起きる、ちょっとぞっとする話です。 要するに、昔からあるBashの書き方を使うと、多くのオープンソースAIコーディングエージェントの防御をすり抜けられる、という指摘です。BashはLinuxやmacOSでよく使われるシェル、つまりコマンドを実行するための仕組みです。見た目はただの文字列でも、Bashに渡すと別の意味に変わることがある。この「変換」が曲者でした。 Adversa AIはこの問題を GuardFall と呼んでいます。私はこの名前、かなり本質を突いていると思います。AI側は「危ないコマンドは弾いたつもり」でも、実際に動く直前にBashが文字列をほどいてしまう。守ったはずの壁が、シェルの都合で崩れるわけです。 古いBashのテクニックで、AIエージェントの防御を回避できる場合がある Adversa AIはオープンソースのAIエージェント11種類を調べ、10種類で何らかの抜け穴を確認した 攻撃のきっかけは、RE