ロカリ

「それ、AIワークフローで殴れるよ」が口癖丨上場企業の部長 × 副業6社でAI・自動化支援丨困ってることは大体同じ、でも"何で解くか"は組織の数だけ違う丨現場の話をポストします

[ロカリ @locali_06]

GPT 5.6 sol 良い！
初めて OpenAIのモデルがClaude のそれを超えてきたと思った。アウトプットのレベルが高く、tokenをそこまで気にしないのが非常に使い勝手が良い。

[ロカリ @locali_06]

Fable5を、Max 20プランにしてぶん回している。祭りすぎる。PCから離れられん。

[ロカリ @locali_06]

fable5 降臨のために、早朝からskillをめちゃくちゃにアップデートしています。ただすぐにlimitが。この6日間のために、Max200ドルにしようか迷い中

[ロカリ @locali_06]

CodexとClaude code 比較して、断然後者なんだけど…
界隈との評判と乖離している、何が原因かわからん
誰か助けて

[ロカリ @locali_06]

仕様だけに時間を使い続けるのも価値が薄いが、実装をぶん回す前に時間を使うところがある

価値を生むのは、仕様に入る前のコンテキストを磨くこと

仮説を導き出す一次情報やユーザー分析などの充実したコンテキストがあればスピーディに検証を回すサイクルに移行すればいいだけかと

[mizchi @mizchi]

仕様駆動開発、個人的には小さなウォーターフォールの再発明でしかないと思っており、愚かな人間が余計な口を挟む仕様レビューしてる時間があったらその時間でエージェントをブン回してプロトタイプ作ってフィードバックループ回したほうがいいと思う

[ロカリ @locali_06]

Claude Codeで、Saasみたいなものができた、とあるが、それを作ったところで意味がない。
それより、価値の届け方を学ぶ/磨くがいいよね、と思っているので共感。

[まさお@AI駆動開発 @AI_masaou]

AIを上手く使いこなせるようになるためには優秀な人と働く/過ごすのが一番だと思う

与えてくれるコンテキストの量感・気遣い全てが絶妙でスマートに入ってくるので参考に

ClaudeCodeを使って目先の他人のプロダクトをパクるより、まず優秀な人の情報共有Context術をパクろう

みんなが幸せになる

[ロカリ @locali_06]

自分でも経験があり、これに陥って空回りパターンに
責任の明確化は現在の組織やチームをより活発にしていける

[30代マネージャーの備忘録。気合いより構造｜100名組織を束ねる管理職 @kabu_nare]

https://t.co/SZxI0akOK3

[ロカリ @locali_06]

気になる..

[Haruhiko Okumura @h_okumura]

AIのリスクといえば個人情報の漏洩が心配という声をよく聞くが、実際にAIに入力した個人情報が漏れたという事件はどれくらいあるんだろうか？

[ロカリ @locali_06]

アウトカムは結果論かもしれないが、評価においては再現性を見るんだろうな

アウトカムの確実性を上げる方法として、プロセス途中での検証の仕組みの設計に尽きる

なぜなら、プロセスを途中で小さな検証を埋め込み、その結果をいかに早く分析を行うか、はその設計によるから

[すぅ| PM & PdM🐈 @suh_sunaneko]

アウトカムが超大事であることはそうなんですが、アウトカムは結果論である場合も多い。アウトカムは当然意識して、目の前のアウトプットを全力でする。特に評価では気をつけないといけない。難しい話だ。

[ロカリ @locali_06]

この意見、参考になる。ちょうど codexと claude codeの連携必要かなー、とか思っていた。
Agent teamあるからな、と思いつつ、言語モデルの特性を使い分け、という観点はできないので、その観点で使い分けてみようかな

[A7.｜AI・データサイエンス @A7_data]

Xでみんな言ってる、

Codexで立案・計画作成→Claude Codeで実装→Codexでレビュー

の流れ、いいね。

結構Claude Code、細かい部分の設計甘いというかぼんやりしてるけどCodexはズバズバ指摘してる

[ロカリ @locali_06]

claude code と codex を連携させてワークさせる、というのもいいが、agent teamとの比較が気になる...

基本的には、自己流の使い方より、一般的に使われるフレームワークに則ってやる方がいいとは思っているものの、それぞれがそこそこ強いので、組み合わせてもみたいw

[ロカリ @locali_06]

すき
最低限の実装、という制約を明確にすることはよく、これを浸透させたい

[miyatti | AI Workflow Palma by Explaza CPO @miyatti]

なぜかMVPというとみんな「雑実装」を想像するのに、MLP（Minimum Loveable Product）——最低限だけどユーザーが「好き！」ってなってくれるプロダクト——というとしっくりくる。でも、MVPもほんとはそういう方向の話なんだよ、という話。
---
Minimum Viable ProductのViableは「最低限の学習（仮説が検証できる）できるくらいには実行可能なプロダクト」という意味で提唱されている。で、その「最低限の仮説の検証」にはいろいろな意味が含まれる——市場があるか、チャネルが成り立つか、価格が合うか、等々。
---
ただ、ほとんどのスタートアップにとって最も重要な仮説は「ユーザーが価値を見出すかどうか」であり、それはほぼ「好ましいと思われるか」という話に行き着く。
---
つまり、MVPをつくる！ってのは基本的には、結果的にMLPに近いものが出てくるはずなんだよね。雑に作っていいという免罪符では断じてない。
---
まぁMVPという言葉の魔力があまりにも強すぎて、仕方ないところあるのでMLPとたびたび言い換えることが多々

[ロカリ @locali_06]

Manus, Genspark 使わんくなった、、解約候補だよなー。

ちなみに、Chat UIで使うものはDeep Researchぐらいになってきたが存在感は強いのでしばらく契約かなー

[ロカリ @locali_06]

Software Engineering is back というタイトルでも響いたが、中身も良かった。
コード1行に向かうより、より大きなコンテキストを考えていくことが求められ、アーキテクトやサービスの設計に費やすことができる環境になってきている、ということ。何か死ぬとか、無くなる、ではないとこもいいね！

[Shin丨AI×プロダクト開発の専門家🤵🏻 @shin_sasaki19]

最近読んだ『Software Engineering is back（ソフトウェアエンジニアリングが戻ってきた）』という記事が、かなり刺さりました。主張はシンプルで「コーディングエージェントが、これまで自分が使ってきたフレームワークを置き換えた」という話📝

ここで言っているのは『vibe coding最高』みたいな軽いノリではなく、むしろ逆で「考える仕事が主役に戻る」という宣言でした。コードを書く労働が軽くなるほど、設計・判断・トレードオフ・エッジケース対応の価値が相対的に上がる。つまり『エンジニアリング』が戻る、という整理。

記事の中で好きだった言い方が「Automated Programming（自動化プログラミング）」です。『タイピングの苦行』が消えて、建築でいうと「レンガを積む」から「建物を設計する」に比重が戻る。服作りでいうと「縫う」から「デザインする」に戻る。こういう比喩って、現場感がないと出てこないんですよね。しかも筆者は「何も考えずにAIに丸投げ」ではなく、アーキテクチャや仕様決定、深夜3時に刺さる地雷みたいな論点は今まで通り（むしろ以前より）考えている、と言います。消えたのは『手を動かす消耗』だ、と。

そして記事が一段深いのは「フレームワークが解決してきた問題」を3つに分解している点です。1つ目が『簡略化』。自分で設計する怖さから、既製の型に逃げる。2つ目が『自動化』。ボイラープレートを減らす。3つ目が本音の部分で『労働コスト最適化』。企業は『ソフトウェアエンジニア』ではなく『React開発者』のような交換しやすい駒を雇いたい。フレームワークはそのための分業装置にもなっていた、という指摘です。ここ、めちゃくちゃ重要です。フレームワーク論に見せかけて、実は組織設計と人材市場の話でもある。

この分解で見える景色は「AIで消えるのはフレームワークではなく『フレームワークに逃げる動機』」かもしれない、ということです。AIエージェントがボイラープレートを量産できるなら『自動化のためにフレームワークを選ぶ』理由が薄れる。さらに、AIが既製の型を超えて「いま目の前の要件」に合わせたコードを生成できるなら『一律の簡略化』のメリットも相対化される。結果として、最終的に残る価値は『設計できる人』に寄っていく。筆者は「問題は『いずれ出るかもしれない課題』ではなく『いま解くべき課題』を解け」と言い切っています。これもAI時代の原則っぽいです。

個人的に「なるほど」と思ったのは、最先端の話の結論が『bashが万能』に落ちているところです。1989年生まれの古い道具が、AIエージェントにとっての『世界との接着剤』になる。派手なMCP設定より、単純なエージェントループ＋bashで充分に価値が出るケースが増えている、という見立てでした。ここから学べるのは「未来は新ツールで来るとは限らない。既存の道具が、別の文脈で最強化される」ということです。プロダクトでも同じで、AI時代に伸びるのは『新機能てんこ盛り』より『基本機能がAIで極限まで強くなる』パターンだったりします。

じゃあこれ、現場では何が起きるのか。自分なりに論点を並べます。
1 『実装力』の定義が変わります。コードを速く書くではなく『意図を正しく伝えて、狙った形に収束させる』が実装力になります。
2 『設計の負債』が可視化されます。AIが速く作るほど、曖昧な仕様や雑な境界設計がボトルネックになります。
3 『ミドル層の二極化』が進みます。記事のコメントにも近いですが、AIはトップの増幅器になりやすい一方、学習ルートが整備されないと格差が広がるリスクがある。だから組織は、育成を『ドキュメント＋レビュー＋意図の言語化』に寄せないと詰みます。

プロダクトマネージャー視点だと、もっと直接的でフレームワーク前提のロードマップが崩れます。今までは「この基盤を入れれば速くなる」「この型に乗れば増員できる」みたいな意思決定が成立していました。でも、AIが『型』の価値を下げるなら、競争優位は「型の選定」ではなく「何を作り、どう検証し、どこで差別化するか」に戻る。つまり、PMの仕事は『仕様を書く人』から『制約条件を設計して勝ち筋に誘導する人』に寄っていく。ここで大事なのは、AIで作るほど『自由度が増える』のではなく、むしろ『自由度を制御できるか』が問われる点です。自由に作れると、人は散らかります。だからこそ、エンジニアリングが戻るというお話かなと👀
https://t.co/KrjGuJlXq9

[ロカリ @locali_06]

Claude Codeで、ワークフローを組むと、このウィンドウだけでデスクワークは完結するんじゃないの、の世界観になる

そこで考えるべきは、（よく言われるが）ただ自動化を行うのではなく、この世界観の中でどうアウトカムを作れるかのための枠組みの再設計なんだろうな

[ロカリ @locali_06]

@aya_howa 流石にdoubtですね。
視野が狭いです。解像度が低い人が使うBIGWordになっているので、もっと限定的にして書くべきです。
求人内容もしくは、相手のスキルでもっと絞らないと。。

[ロカリ @locali_06]

やっぱ、これだね。
もう一つだけ付け足すと、AIを使うためのことはテクニックより、いかに抽象度を上げての思考プロセスを型化していくか、ということなので、実は使い始めて、その概念が分かり始めるとすぐに追いつける、ということも良いので怖がらず、とりあえず一歩踏み出せばいいと思う。

[すぅ| PM & PdM🐈 @suh_sunaneko]

これからAIやろうとしている人に対して、AIガチ勢の経験値マウントや本質マウントはダサいよ。最初はみんな恐る恐る触ってみることからはじめるんですよ。それの何が悪いのか。AIリテラシー高くても人間リテラシー低すぎると思います。

[ロカリ @locali_06]

この機能を使わないと今後やばい、とかの不安を煽る系もあるけど、このようなポジティブな気持ちで使っていく方がいいよね
単純に知的好奇心が強い方がいい

[なかじ / 中島大介@ウェブ職TV @ds_nakajima]

Claude Codeのエージェントチーム機能は成果物がどうこうよりも、自分の手元に未来を感じることができるのがたまらない。

[ロカリ @locali_06]

codex appも使ってみないとなー。
先週は、claude code がagent teamを発表してそっちに気を取られた...
繰り返し作業はこっちの方がロングランしそうな期待もあるので、これを参考に触ってみます。

[Shinji Yamada @santa128bit]

自分なりのCodex Appのいい感じの使い方まとめ。
Codex Appには細かい便利機能がたくさんあるので、なんとなく使ってるだけだと損をしますね。

https://t.co/JKcAAVC6tK