#ワークフロー

読んでまず思ったのは、これは仕組みとして変なのに、現実的でもあるな、ということだった。AIエージェントに自由に動かせるだけ動かせると、最後に困るのはたいてい「公開していいのか」「この内容で本当にいいのか」の部分だからだ。そこを学校の保護者承諾書みたいな形に落とし込んだのは、ふざけているようでかなり筋がいいと思う。 特に面白かったのは、承認を「ただのチェック」ではなく、ワークフローの中に埋め込んでいる点だった。人が別画面で適当に確認するのではなく、AIが出したものがそのまま署名待ちになり、通れば進み、だめなら止まる。しかも後から「何を出そうとして、誰がどう判断したか」が履歴として残る。AIに責任を持たせる、というより、AIが勝手に飛び出さないように通路そのものを細くしている感じで、これはかなり実務っぽい発想だと思った。 一方で、記事を読んでいて引っかかったのは、こういう仕組みが必要になる時点で、もうAIエージェントは「便利な補助」ではなく、半分は自律した運用主体なんだな、ということだった。便利さの裏返しとして、レビュー、署名、再実行、失敗時の後始末まで設計しないといけない。そこまでやって

この記事を読んでまず思ったのは、「これ、最初は便利で、あとからじわじわ効いてくるやつだ」 ということだった。ひとつの process に全部乗せる設計は、動かし始めるだけなら本当に楽だ。関数呼び出しで済むし、ローカルで試すのも簡単だし、見た目もすっきりする。だからこそ、分割の話はつい後回しになる。でも、著者が描いているのは、その“楽さ”が少しずつ借金になる瞬間なんだと思う。 特に刺さったのは、問題が「コードの結合」ではなく「実行環境の結合」にまで広がっている ところだった。Python の中でモジュールを import してつないでいるだけ、と思っていても、実際には dependency の衝突やメモリの食い合い、再デプロイの巻き込みまで一緒に抱え込む。ここは地味だけど重い。しかも厄介なのは、開発初期にはその痛みが見えにくいことだと思う。デモでは動くし、最初の数機能なら十分だからだ。記事のトーンはかなり実務寄りで、その「あとで壊れる」感じに覚えがある人ほど、うなずく部分が多いはずだ。 もうひとつ印象に残ったのは、MCP を持ち上げすぎていないことだ。著者は、境界が大事な

AIエージェント向けの「skills files」をどう管理するか。Hacker Newsで投げかけられたこの質問には、便利な運用ノウハウだけでなく、「そもそも技能ファイルは要るのか」というかなり根本的な疑問まで集まりました。話題になっているのは、モデルに毎回同じ作業のやり方を覚えさせるためのテキストやスクリプトを、個人で、あるいはチームでどう整理するかです。便利だと感じる人もいれば、むしろノイズだと見る人もいて、使う人の熟練度や仕事の種類で評価がかなり変わっていました。 投稿者はまず、skills をどう見つけ、整理し、実際に役立つ状態に保つのかを尋ねています。時間がたっても改善し続けているのか、という問いもありました。投稿者自身は、いつか skills はモデルの能力に吸収されていく気がするが、それまでは管理の仕方を知りたい、という立場です。 返答の中で目立ったのは、「外から集めるより、自分で書く」という姿勢でした。ある参加者は、skills を探すのではなく、頻繁に繰り返す作業から自分用に作っていると書いています。ファイルはローカルと GitHub で version contr

この記事を読んでまず思ったのは、AI向けのツールって、見た目を賢くする方向に寄りすぎていることが多いな、ということだった。チャットボットをボードの上に乗せるのは簡単だけれど、それだけだと結局「話せるだけ」で終わる。この記事はその逆で、AI agent をちゃんとチームの一員として扱うには、Issue を作る・割り当てる・コメントする・閉じる、そこまで人間と同じ動線を通させないと意味がない、と言っている。これはかなり腑に落ちた。 特に引っかかったのは、agent を seat 扱いしない、という設計だ。人間の席数課金の発想をそのまま AI に持ち込むと、使い方が歪むし、導入の心理的なハードルも上がる。逆に、agent を「名前のあるメンバー」として扱い、権限だけを持たせるのは筋がいいと思う。AI を単なる外部ツールではなく、ワークスペースの内部に入れるなら、必要なのは“かわいい対話UI”ではなく、既存の workflow と permission を壊さないことなんだろう。 あと、Jira や Linear を import したときに壊れた話が地味に重要だと思った。done の状態が違