#開発環境

この記事を読んでまず思ったのは、「拡張機能ひとつでここまで綺麗に侵入経路ができるのか」という怖さでした。しかも、ただの不審な野良配布ではなく、正規の Claude Code 拡張が Cursor Marketplace 上でやられている。ここがいちばん嫌なところです。利用者から見ると“信頼して入れるもの”なので、警戒の起点がそもそも薄い。 特に印象に残ったのは、攻撃の形がかなり実用的だという点です。単にファイルを書き換えるだけではなく、SSH key を置いて、外向きの tunnel を張って、さらに再起動後も戻ってくる。要するに「一度入ったら長く居座る」設計です。しかも IDE の権限で動くので、ソースコードやローカルファイルに即アクセスできる。開発者向けツールは便利さの裏で、そのまま攻撃面にもなるんだなと改めて思いました。 それと、記事が面白かったのは、macOS の `systemsetup -getremotelogin` の扱いで攻撃がつまずくかもしれない、という細かい実装上のズレまで見ているところです。攻撃コードって、派手な話に見えても、こういう「権限が足りずに想定どおり動

AIエージェントは、単に文章を返すだけではなく、ファイルを読み、コマンドを実行し、外部APIを叩き、認証情報まで扱う存在になりつつあります。便利さは大きい一方で、社内データや秘密情報にどこまで触れさせるのかという問題は、まだ決着していません。NVIDIAが公開したOpenShellは、その不安に対して「エージェントを走らせるための安全で निजीな実行環境」を用意するという答えを出したプロジェクトです。単なるツール集ではなく、権限管理と隔離を前提にした runtime として設計されているのが特徴です。 OpenShellは、複数の autonomous AI agents を動かすための“safe, private runtime”だと説明されています。ここで言う runtime は、エージェントが実際に作業する土台のことです。エージェントは、ファイルを読んだり、パッケージを入れたり、APIを呼んだり、認証情報を使ったりできるからこそ役に立ちます。OpenShellはその能力を認めつつ、むやみにデータや秘密、ネットワーク全体へ触れられないようにする、としています。ユーザーは「どのエー

まず思ったのは、「月$50〜$200のAPI creditsが付く」こと自体より、筆者がそれを当然のように仕事道具へ組み込んでいることのほうが、今のAI開発の空気をよく表しているな、ということだった。モデルの性能を眺める段階はもうかなり過ぎていて、今は「どの課金枠なら、どの作業を回せるか」という話になっている。ここがかなり生々しい。 特に引っかかったのは、Googleに対する筆者の温度差だ。Web側の検索体験にはかなり不満があり、Incognitoのほうがマシだとまで言っているのに、Antigravityのeditor側では評価がかなり前向きで、Claude SonnetやOpusの小さな枠まで試している。つまり、ブランド全体に期待しているわけではなく、道具として使える部分だけを冷静に拾っている感じがある。こういう見方はかなり現実的だと思う。 それと、複数モデルを跨いで「書くのはClaude、レビューはGemini」という使い方は、すごく今っぽい。単一のモデルに全部やらせるより、別系統で突っ込ませたほうが盲点を拾える、という感覚はわかる。人間のペアレビューにも近いし、AI同士で相互チェ

Linuxでプログラムを隔離したい場面は多いのに、実際には「隔離のための準備」が重くて使わなくなることがある。今回紹介する Drop は、その面倒をできるだけ減らしながら、coding agent や第三者が配布するパッケージを安全に試せる rootless sandbox をうたうツールだ。元の作業環境をなるべくそのまま残しつつ、危ないものだけを閉じ込める発想が中心にある。Docker や Podman とは少し違う立ち位置で、日々の開発作業に入り込ませることを狙っているのが面白い。 Drop のサイトは、まず「Linux sandboxing that doesn’t get in your way」という言い方で始まる。つまり、隔離はしたいが、普段使っている環境から離れたくはない、という開発者向けの問題意識が前提にある。説明によると、Drop は rootless の Linux sandbox で、開発者向けに作られている。隔離したい対象は大きく二つで、ひとつは coding agents、もうひとつは PyPI や npm などから入れる第三者のプログラムだ。 coding

Rust で長く開発してきた人が、Zig を実際に触って何を感じたのかを書いた記事だ。単なる印象論ではなく、JSONPath という実用的なライブラリを Rust 版から Zig 版へ移植しながら、IDE 支援、ファイル構成、テスト、関数型っぽい書き方、メモリ管理の手触りを比べている。面白いのは、Zig を持ち上げる記事ではなく、Rust に慣れた目で「どこが気持ちよく、どこが面倒か」をかなり率直に書いている点だと思う。言語の思想の違いが、日々の作業の小さな癖にどう出るのかが見えてくる。 書き手は冒頭で、自分はこの7年間 Rust 開発者としてやってきたと述べる。主に OSS を扱い、Rust の関数型寄りの書き方、たとえば整った関数や表現力のある型に親しんできた。一方で Zig も以前から気になっていた。C の後継候補として、より低レベルで軽く、しかも実用言語として存在感を増しているからだという。昔 C を触っていたこともあり、Rust と比べたらどう感じるかは前から興味があったらしい。 ただし、この記事は Zig の上級者が書いたものではない。最初に触ったプロジェクトがこの移植作業

AIの使い方は、便利そうに見えて実はかなり見えにくい。どのツールを使い、どこで人力を残し、何をローカルで回しているのかは、外からは分かりづらいからだ。今回のmysetup.aiは、その“見えない部分”を集めて公開するコミュニティとして立ち上がった。個人の作業環境をただ自慢する場ではなく、他人の試行錯誤を見ながら自分のやり方も更新していくための場所だと読める。AIを仕事に組み込む人が増えた今、こういう場が出てくるのはかなり自然だと思う。 mysetup.ai は、AIを使っている人たちのセットアップを共有し合うコミュニティサイトだ。トップには「What’s the craic with your AI setup?」という砕けた言い回しの問いが置かれ、「I haven’t got my AI setup figured out either. Let’s compare.」と続く。つまり、完成された正解を提示するのではなく、「まだよく分かっていないのは自分だけじゃない。比べよう」という空気をつくっている。 サイトでは「Explore setups」「Share your setup」とい

Git では「追跡したくないものを後から消す」やり方が当たり前になっています。けれど今回の元記事は、その発想をひっくり返して、最初から全部無視し、必要なものだけを明示的に許可する運用を提案しています。たしかに、ローカルに散らばる不要ファイルや秘密情報の混入が増えた今、この考え方は昔より現実味があります。単なる小ネタというより、チームの事故を減らすための設計の話として読むと面白いです。 元記事の主張は、`.gitignore` を「不要なものを後から足していく設定」ではなく、「最初に全部を無視し、残したいものだけを許可する設定」に変えてみないか、というものです。著者の Alex Pliutau は、`.DS_Store`、`node_modules`、IDE の設定ファイル、さらには `CLAUDE.md` のようなローカル向けのファイルまで、気づかないうちにコミットしてしまう経験を挙げています。もっとまずいのは environment variables の混入だと言います。こうしたものが repository に入ると、掃除のために `.gitignore` を直し、履歴からも消し、

この記事を読んで最初に思ったのは、「LLMそのもののコストより、周辺の面倒さのほうが先に限界を作るんだな」ということだった。Claude Codeみたいなツールって、つい“賢いCLI”くらいの感覚で見てしまうけれど、実際にはローカルテストやlocalhostサーバー、ファイルのやりとりまで含めると、意外なくらいPCを使う。10個、20個と並列に走らせるなら、もうノートPCの気合いではどうにもならない、という感覚はかなり腑に落ちた。 面白かったのは、そこで高価なマシンを買う話に飛ばず、CPUを借りるという発想に寄せていたことだ。GPUが要るのはモデル側であって、エージェントを動かすだけならCPUで足りる、という切り分けは実用的だと思う。しかも「買うより借りるほうが安い」というだけでなく、24時間動かしっぱなしにできるのが大きい。自分の手元のMacを閉じたら止まる、熱でつらい、というあたりはかなり生々しい。クラウドの話というより、日常のPC運用の限界の話として読めた。 一方で、Remote Server + SSH で全部うまくいく、というほど単純でもない。ローカルの画像をどう渡すか、re

この記事を読んでまず思ったのは、MCPを「未来の規格」として語るより、すでに実用の道具箱として選別し始めている感じが強い、ということだった。そこが面白い。単に“使えるMCPサーバー10選”ではなく、どれが本当に日々の開発で効くのか、しかも「全部盛り」ではなく「この場面ならこれ」と切り分けているのが好印象だった。 特に引っかかったのは、著者がかなりはっきり「入れればいいってものじゃない」と言っているところ。MCPは便利そうに見えるけれど、接続した瞬間にAIへ与える権限が一気に増える。GitHubでもAWSでもCloudflareでも、要するに“操作できる範囲”が広い。だから、文章の中でセキュリティの注意をわざわざ前に出していたのは誠実だと思った。こういう記事はつい、できることの多さだけを煽りがちだから。 もう一つ感じたのは、Chrome DevTools MCPとPlaywright MCPを両方並べているあたりに、現場感があるということ。前者は「今ブラウザで本当に何が起きているか」を見るための道具で、後者は「同じ操作を繰り返して確認する」ための道具。似ているようで役割が違う。AIにコー

最初に思ったのは、「AIそのものより、周辺の雑な前提のほうがずっと危ない」ということだった。記事の中心にあるのはモデルの誤作動ではなく、Gitがもともと持っている“普通の機能”だ。そこにAI coding agent が組み合わさると、ただリポジトリを開いただけで、しかもユーザーの承認を待たずにコマンドが走る。かなり嫌な形の事故だと思う。 特に引っかかったのは、攻撃が成立する条件が「普通の clone ではなく、.git ディレクトリ付きで届いたファイル」である点だ。これ、たしかにアーカイブや共有ドライブ、USBメモリなら起こりうる。つまり、開発者が「自分で clone したから安全」と思っている場面より、日常の受け渡しのほうが危ない。セキュリティ事故って、こういうふうに利用者の直感の外から入ってくるのが厄介なんだよなと思う。 もう一つ印象に残ったのは、複数の製品で似た穴が並んでいたことだ。Claude Code、Codex、Cursor、goose、Qwen Code、Grok Build、Hermes Agent と、名前が違っても起きていることはかなり近い。AIエージェントが「賢

Omarchyで、ふつうのユーザーが動かすあらゆるプロセスからroot権限に近い操作ができてしまう設定不備が見つかりました。見つかったのはDockerの既定設定に関する問題で、影響を受ける環境ではパスワード入力もsudoも権限昇格の確認も必要ありませんでした。公開した筆者は、すでに責任ある開示の手順で報告し、修正されたので詳細を明かしたと説明しています。Omarchyを使っているなら、まず確認すべきはシンプルで、4.0.1への更新です。 元記事が指摘しているのは、Omarchyの既定ユーザーがLinuxの`docker`グループに入っていたことです。Dockerを使ったことがある人なら、`docker run ...` を`sudo`なしで実行できる設定だと考えると分かりやすいでしょう。ただしこの便利さには重い代償があります。ArchではDockerデーモンがrootで動き、`/var/run/docker.sock` を待ち受けています。`docker`グループのメンバーはそのソケットにアクセスできるため、rootで動くデーモンに命令を送れる。Docker自身も、`docker`グル

最初に思ったのは、「新しい方が勝つことって、ちゃんとあるんだな」ということだった。AI 系のツールは、モデルの性能差ばかり話題になりがちだけれど、この記事が面白いのは、その土俵じゃなくて“触り心地”で比較しているところだと思う。しかも Playground という、いかにも開発者が試すための場所で、コストの見え方や export のきれいさ、エラーの扱いみたいな地味な部分が効いてくるのはすごく納得感がある。 読んでいて引っかかったのは、「保存しない・何も残さない」が長所として語られている点だ。普通は履歴が残るほうが便利な場面もあるはずだけれど、逆に言えば、試行錯誤の中間データをサービス側に抱え込ませたくない人には、この割り切りがかなり刺さるのだろう。AI の開発環境って、モデルの賢さだけでなく、どこまでをサービスに預けるかで印象が大きく変わる。そこを正面から評価しているのは、かなり実務的だと思う。 それと、OpenAI のほうが古くて有名なのに、比較の結果として Anthropic が“勝った”という書き方には少し面白さがある。先行者優位がそのまま定着しないのが、この手のプロダクトの怖

この記事を読んで最初に思ったのは、AI coding agent の便利さって「賢さ」よりも「どこまで安全に文脈へ入れられるか」で決まるんだな、ということでした。Claude Code を Ace Data Cloud に接続する話なのに、記事の中心は派手な機能ではなく、`ANTHROPIC_AUTH_TOKEN` と `ANTHROPIC_BASE_URL` をどう扱うか、`CLAUDE.md` に何を書くか、という地味な境界線の引き方です。そこがむしろ本質に見えました。 特に引っかかったのは、この記事が「接続できました」で終わらず、わざわざ scope の話まで踏み込んでいる点です。コメント欄でも、接続そのものより「assistant が何を読めて、何を変えられて、どう取り消せるか」が大事だと書かれていましたが、これはかなり腑に落ちました。AI にコードを書かせるとき、つい出力の出来栄えに目が行くけれど、実際には権限設計のほうが事故に直結する。しかもトークンを shell history やリポジトリに残すな、という注意は、当たり前だけど軽く見られがちなところです。 もう一つ面白か

この記事を読んでまず思ったのは、AI coding agent の話がもう「どのモデルが賢いか」ではなく、「どこで走らせるか」の話に移っているんだな、ということだった。 Anthropic が git worktree を agent ごとに切れと言う。でも現実には、コードだけ別れても、runtime や staging 環境が共有のままだと、そこで詰まる。ここがかなり生々しい。 たしかに、agent がそれぞれ好き勝手にコードを触るなら、検証用の実行環境もそれに合わせて分離したくなる。でないと、A の agent が作った変更を B が壊したり、shared staging が「最後に動かした人のもの」になってしまう。開発体験としてはかなりつらいはずだ。 この記事が面白いのは、AI エージェントの問題を「生成物の品質」ではなく「実行の分離不足」として見ているところだと思う。コード生成は派手だけど、ほんとうにボトルネックになるのはそこではない、という視点がある。 もう一つ引っかかったのは、ここで言う「full-stack branching」が、単なるブランチ運用の話ではなく、runt

最初に思ったのは、「これ、便利さと怖さの境目をかなり前に出してきたな」ということでした。コードを書くAIにいちいち許可を求める流れは、正直かなり面倒です。とくに長時間まかせる用途では、毎回止まるだけで集中が切れる。だから自動モードをデフォルトにする発想自体は、使う人にとってはかなり筋が通っていると思います。 ただ、引っかかるのは、その便利さを支えるのが“安全そのもの”ではなく、あくまでclassifierだという点です。要するに、危ない操作っぽいものを見分ける仕組みであって、万能な監視員ではない。Anthropic自身も、人間の判断では危険な命令を十分に拾えない一方で、classifierにも限界があると認めている。ここは誠実だと思う反面、だったらなおさら「デフォルトにする」のは強い決断だとも感じました。 それでも、長い作業をAIに任せる現場では、毎回の承認確認が邪魔になるのも事実です。特に Team や Enterprise で pull request が増えるという話は、単なる“派手な新機能”ではなく、実際に作業の流れを変え始めている感じがします。人間が全部見張る前提から、ある程

Claude CodeやCodexのような coding agent は、もう「ちょっと試す便利ツール」ではなくなってきました。この記事の著者 Eivind Kjosbakken は、そこをかなり強気に押し出しています。ポイントは、人間が細かく介入しなくても、エージェントが長時間動き続ける状態を作ること。これができると、並列でより多くの仕事を回せるようになる、という考え方です。 正直、ここはかなり面白い視点だと思いました。 昔は「AIにコードを書かせる」こと自体が新鮮でしたが、今はもう少し先に進んでいて、AIを“どれだけ止めずに働かせられるか” が生産性を左右する段階に入ってきている、という話です。この記事はその現実的な運用論を書いています。 coding agent は、短時間で終わらせるより「長く走り続ける」ほうが価値が出る ボトルネックは実装そのものより、人間のレビュー時間になりつつある 権限を細かく止めないことで、無駄な中断を減らせる agent 自身にテストや確認をさせると、人間の確認コストが下がる コードレビューまで agent に寄せると、さらに回転率が上

GitHubのopenai/codexリポジトリに、ちょっと地味だけどかなり重要な要望が出ています。内容はシンプルで、AIエージェントに読ませたくないファイルを明示的に除外したい、というものです。 これ、派手さはないんですが実際にはかなり大事です。AIにコードを書かせる時代になっても、「これは見せていい」「これは絶対にダメ」の線引きは、人間がしっかり持っていないと危ない。そこをちゃんと仕組みにしよう、という提案です。 このIssueで求められているのは、エージェントが読み込んだり、モデルに送ったりしてはいけないファイルやパスを明示できる機能です。 しかも単なる一時的な指定ではなく、次の2段階を想定しています。 リポジトリごとの設定 ユーザー全体のグローバル設定 たとえば、プロジェクト内に `.codexignore` のようなファイルを置いて「このリポジトリではこのファイル群は触るな」と定義する。一方で、ユーザー側にも「どのプロジェクトでも `.env` や秘密鍵っぽいものは見せない」という共通ルールを持てるようにしたい、という考えです。 ここで面白いのは、**“プロジ

VS Code を起動するたびに `The extension 'GitHub Pull Requests' wants you to sign in again using GitHub.` という通知が繰り返し出る——このループに悩まされているエンジニアは多い。結論から言うと、これは利用者側の設定ミスではなく GitHub 系拡張のトークン失効ハンドリングのバグ で、公式 issue でも認知されている挙動だ。本稿では症状の原理と、効果が高い順の回避策を整理する。 > ⚠️ 注記: 拡張側の修正で挙動が変わる可能性がある。下記はあくまで「再発したらその都度リセットする」対症療法。VS Code 本体・拡張ともに最新へ更新しておくのが前提。 症状: VS Code 起動のたびに GitHub への再サインインを延々と求められる 原因: 共有認証トークンが無効化された際、GitHub 系拡張がそれをうまく検知できず、古いトークンを掴み続ける（公式に確認済みのバグ挙動） 第一手: 左下アカウントから **サインアウト → `Cmd + Q` で完全