#開発運用

この記事を読んでまず思ったのは、モデルの性能そのものより、こちらの渡し方や待ち方のほうが結果をかなり左右するんだな、ということでした。 Opus 5.5 は「長く自走する」「途中経過をちゃんと説明する」「毎回すぐ答えるとは限らない」という前提で扱うと、かなり頼もしい。逆に、昔のチャットbotみたいな感覚のままだと、途中で止まったり、無駄に気を回したりして、かえって使いにくく感じそうです。 特に印象に残ったのは、「think carefully」みたいな文言を消せ、という部分です。ふつうは丁寧に思考させたほうが良さそうに見えるのに、このモデルではそれがもう効いていない。むしろ余計な指示があると、返答が遅くなることがある。ここは少し皮肉で、AIを賢くする呪文を足すより、古い呪文を捨てるほうが効く、という話に見えました。 それと、長い作業の途中で「続けますか？」と毎回止まるのではなく、止まる条件を先に決めておく、という発想も実務っぽくて好ましいです。Claude Code の CLAUDE.md に「どこまで勝手に進んでよいか」を書いておくのは、単なる小技というより、チームで作業する時のルー

GitHubのプロジェクトで、ドキュメントを wiki に置くべきか、それともリポジトリ内の `/docs` フォルダに置くべきか。この記事は、その定番の悩みにかなりはっきりした答えを出しています。筆者は wiki の利点を認めつつも、実際には欠点のほうが多く、GitHub の wiki はアンチパターンだとまで言い切ります。単なる好みの話ではなく、利用者と保守者の両方にとってどちらが扱いやすいか、という視点で整理しているのがポイントです。 元記事は、GitHub プロジェクトで「wiki を使うべきか、`/docs` フォルダを使うべきか」という議論が半年おきくらいに出てくる、と前置きしたうえで、自分の考えを明文化したものです。筆者は当初、「wiki でも `/docs` でもどちらも正しい選択肢」と書き始めたそうですが、書き進めるうちに見方が変わり、wiki を使う理由はほぼ一つしかないのに、使わない理由はたくさんあると結論づけています。そのため、GitHub の wiki はアンチパターンだと位置づけました。 筆者が認める wiki の利点は、リポジトリのどこからでも一クリックで

読んでまず思ったのは、「ああ、これはかなり地味だけど本当に効くやつだな」ということだった。MCP server の話ではあるけれど、実際にはどんな申請制の審査にもそのまま刺さる感覚がある。動くかどうかより、「審査する側に何が見える状態で出すか」のほうがずっと厄介なんだよな、と改めて思った。 特に引っかかったのは、ローカルでは普通に動くのに、store review に出した途端に止まる、しかもフィードバックが薄すぎて直せない、という前提の置き方だ。これ、開発者からするとかなり消耗する。バグがあるならまだしも、「何を直せばいいのか分からない」というのは、技術というより運用の問題に見える。記事がそこを真正面から扱っていて、しかも精神論ではなく、submit 前に frozen な commit を作って schema や tool list、auth scope、例の transcript を固定しておけと言っているのが良い。 僕はこの手の話で、CI を通したら安心してしまう瞬間がある。でもこの記事の感覚だと、CI は合格証ではなく、せいぜい「自分たちの手元では壊れていません」の証明にすぎ

Google Playのアプリ審査が遅すぎる、と開発者が公開の場で強い不満をぶつけています。今回取り上げるのは、長年Android向けアプリを続けてきた作者が、更新申請の審査に1週間以上かかる状況を「許容できない」と書いた投稿です。単なる愚痴ではなく、月1回しか更新しないような古いアプリにまでこの遅さが及んでいることへの抗議でもあります。配信の入口を握るGoogle Playの運用が、現場の開発リズムを壊しているという話です。 発端は、Mastodonに投稿されたDaniel Gultschの短いメッセージです。彼は「This is unacceptable」と切り出し、Google Playのアプリ審査プロセスが「now regularly takes longer than a week」、つまり今では定期的に1週間以上かかると訴えました。ここで言っているのは、アプリを新しく公開する審査ではなく、すでに配信されているアプリの更新を通すときのレビューです。Androidでは、修正や機能追加、セキュリティ対応のたびにこの審査を通す必要があり、ここが止まると配信全体が詰まります。 Gul

最初に思ったのは、「ここまでやるのか」という驚きだった。PR を作るだけでも面倒なのに、CI が落ちたら直し、レビューコメントまで拾って反映し、最後は merge まで進める。人間が普段やっている“地味で切れ目のない作業”を、そのままひとつの流れとして差し出してくるのが面白い。単なるコード生成ツールというより、開発の進行役を置こうとしている感じがある。 ただ、読んでいて一番引っかかったのは、便利さそのものより「どこまで任せてよいのか」が曖昧なところだった。失敗したテストを直すのはまだわかる。でもレビューコメントに応じてコードを変え、承認がついたら自動で merge するとなると、誰が最後の責任を持つのかが急に重くなる。人間が見なくても進むほど、うまくいったときは気持ちいいけれど、何かおかしいときに気づくのは遅れそうだと思う。 一方で、状態をディスクに保存して途中から再開できるとか、REST API や webhook で外からつなげられるとかは、かなり実務向きだと感じた。こういうツールは派手なデモで終わりがちだけど、止まったあとに再開できるか、他のシステムとつながるかで使い勝手が全然違

読んでいてまず思ったのは、Claude Code みたいな「勝手に動くAIエージェント」では、READMEやCLAUDE.mdが思った以上に設計そのものになるんだな、ということだった。ふつう設定ファイルは、せいぜいツールの癖を合わせるための補助線くらいに見える。でもこの記事を読むと、そこがもう単なる補助ではなくて、AIの挙動を縛る“現場のルールブック”になっている。 特に引っかかったのは、コンテキストがプロンプトと別物だと強く扱っている点だ。人間なら「この指示はこの場だけ」と空気で分かるけれど、AIはそうはいかない。いったん渡した情報が、どこまで効いていて、どこから効かないのかが曖昧だと、便利さより先に事故のほうが目立つ。だから「CLAUDE.mdに何を書けるか」より、「何を書いてはいけないか」「どこで指示を切るか」を細かく詰めているのが面白い。AIが賢くなるほど、雑な指示は雑な結果として返ってくる、という当たり前がかなり露骨に出ている。 もう一つ、少し怖さもある。記事では“ベストプラクティス”として整理されているけれど、実際には運用の知識がかなり重要になる。スキルやアーティファクトま

この記事を読んでまず思ったのは、こういう機能は派手さのわりにかなり効く、ということだった。Claude Code のような開発支援ツールって、便利になるほど「誰が何をしたか」を後から追いにくくなる。だから Compliance API みたいに、監査や統制のための入口を別に用意する発想は、地味だけど筋がいいと思う。 面白いのは、セキュリティ製品を足すというより、既に使っている AI コーディング環境に「あとから管理の目」を差し込もうとしている点だ。現場では、禁止するより先に使われることのほうが多い。だったら、使われる前提でログや権限、追跡を整えるしかない。そこを真正面からやっている感じがある。 ただ、ここで少し引っかかったのは、Compliance API があっても、それだけで安心はできないだろうという点だ。API があるのは入口であって、実際には運用側が何を監視し、どこまで許可し、誰が責任を持つのかを決めないと意味が薄い。監査のための機能は、導入した瞬間よりも、使い続ける運用のほうがずっと難しい。 AI を開発に入れる話は、どうしても「生産性が上がる」で終わりがちだけれど、この記事

いちばん面白かったのは、Warp が改善を「モデルの頭の中」や「雑なメモ」に寄せず、ちゃんと PR と review の流れに乗る形へ落としている点だった。AI の出力が少しずつ良くなる、という話自体はよく聞くけれど、実際にそれを“人間が普段やっている開発の回路”の中に埋め込むと、こんなに筋が通るのかと思った。 特に引っかかったのは、フィードバックが session の終わりと一緒に消えてしまう、という指摘だ。これは地味だけれどかなり本質的だと思う。普通のチャットだと、良い指摘があっても次回に自然には引き継がれない。そこで skills という file-based な単位に知識を残し、改善担当の agent が後からそれを読んで小さく直す。つまり「覚えておく」のではなく、「直すべき文書を直す」。この考え方は、AI を魔法っぽく扱わず、むしろソフトウェアの変更管理に寄せている感じがして好感があった。 もう一つ、地味に効いていると思ったのは「rules ではなく principles を書け」という話。AI に細かい禁止事項を並べるより、なぜそうするのかまで含めて書くほうが、たしかに汎用

この記事を読んでまず思ったのは、やっぱりAIコーディングは「魔法の便利機能」ではなく、運用の話になってきたんだな、ということだった。Claude Codeそのものの出来よりも、どう使うか、誰がどこまで触っていいか、どの環境に載せるかのほうが重くなっている。ここが地味だけど本質だと思う。 特に引っかかったのは、「Claude Codeが強い」という話の隣で、結局は企業が使うならガバナンスや権限管理が先に来る、という空気がはっきりしていたところ。サブエージェントとかコンテキストロットみたいな話は、個人の開発だと「へえ、賢そう」で済む。でも組織に入ると、勝手に触られたくない領域、レビューの責任、トークンやコストの扱いが一気に現実になる。AIがコードを書く速度より、その周辺の調整のほうが遅い。そこはかなり実感がある。 それと、記事の中で「2年で2か月に短縮」といった話が出てくるのも、少しだけ怖い。実際、AI導入の速度感はそういうふうに見えるのだろう。ただ、短縮されたのがPoCの立ち上げなのか、本番運用なのかで意味は全然違う。そこは記事だけでは見えにくいし、むしろ知りたかった。AIがすごい、とい

この記事を読んでまず思ったのは、「ここまでやると、もう“ツール一覧”というより“生きている収集システム”だな」ということだった。手でリンクを集めて並べる段階を飛び越えて、web を巡回し、LLM が内容を解釈し、重複を見て、さらに Hugging Face に毎晩流し込む。発想としてはかなり素直だけれど、実装としてはかなり野心的だと思う。 面白いのは、単なる検索強化ではなく、`intent-based categories` を前面に置いているところだ。キーワード一致ではなく「何をしたい人向けか」で分類する、というのは理屈としてはわかるし、実際かなり便利そうだ。ただ、その分類を Llama 3.3 にかなり任せているのが少し引っかかった。意図の解釈って、見た目以上にぶれやすい。雑な分類が積み重なると、検索体験が賢くなるどころか、逆に「それっぽいけど外れてる」データベースになりやすいからだ。そこをどう評価しているのかは、もっと知りたくなった。 もうひとつ印象に残ったのは、MCP server を立てて IDE から直接検索できるようにした点だ。これは単に「AI を使っています」という話で

Claude Code Docs の新しい機能「routines」は、ひと言でいうとClaude Code をスケジュール実行・API起動・GitHubイベント連動で自動運転させる仕組みです。 しかも、ただの「定期実行」ではありません。Anthropic 管理のクラウド上で動くので、手元のPCを閉じても止まりません。ここがかなり大きい。ローカルで動く自動化は、結局「PCをつけっぱなしにする人が勝つ」世界になりがちですが、routines はその弱点をかなりきれいに消しています。 routines は、Claude Code の保存済み設定を自動実行する仕組み 実行場所は Anthropic 管理のクラウドなので、PCを閉じても動く トリガーは Schedule / API / GitHub の3種類 1つの routine に複数トリガーを組み合わせられる 使えるのは Pro / Max / Team / Enterprise かつ Claude Code on the web が有効な場合 研究プレビュー段階なので、**挙動や制限は変わる可能性