渡邉行人

「AIが効かない会社」の問題はAIじゃなくて、自社を言語化できていないことだったという話📝 ■ 問題はAIではなく「自社を説明できないこと」 ・AIは実行の技術。何をやるかが不明確な会社では効かない ・多くの会社は『なんとなく成功しているカオスなブラックボックス』状態 ・ゴール・戦略・課題・業務を即答できる会社はごく一部 技術的な準備ではなく、自己認識の問題 ■ AIで伸びる会社の共通点 ・顧客の課題、自社のゴール、指標、戦略、プロジェクト、コストを即答できる ・その答えが四半期や年をまたいでもほぼ変わらない 答えが毎回変わる会社は、上に良く見える答えを書いているだけ ・AIで伸びている会社は偶然ではなく、もとから語れる会社 ■ いま起きている分岐 ・エンタープライズのAI活用はまだほぼ始まっていない ・自社を語れない会社は、語れる会社からの脅威に晒される ・小さな会社が大企業並みのアウトプットを出せる時代へ 問うべきは『AIが何をしてくれるか』ではなく『自社がAIで助けられる状態か』

"AIは「速く作る力」を育てるが、「深く理解する力」を奪う" これからエンジニア組織の構造は2つの方向に分岐する 1. AIの乗数効果を組織として制御できる企業群 2. AIの普及率だけを追いかけ、品質の崩壊に気づくのが遅れる企業群 / AIは速度を前払いし、失敗を後払いにする htn.to/21ZBLQiq3V

AIによって知的労働のコストがダダ下がりしてることに皆早く気づいてほしいなぁ それ前提でROI測らないと 健全な意思決定はできない

colab mcp サクッとAIモデル試したい時に使えそう zenn.dev/ncdc/articles/…

ビジネスモデルって言葉はなんか漠然してるけどほぼKGIとKPIとCSFのふわっとした概要ってイメージかなぁ 実行可能なレベルまで分解して検討しないとただの絵空事になっちゃう 耳が痛い

「Anthropic・Claude Code」がなぜこんなにも早く開発できるのか？がかなり勉強になったのでシェアです！ ただ、他のSaaSに適用しようにも難しい部分も多そうで、いくつか応用したり形を変える必要がありそうと感じたので、僕自身が感じたこと・考えたことも含めて投稿します。 1. UI を含めたプロトタイプ作成の難しさ UIがあるアプリケーションの場合、画面の考え方・操作性・何を配置するか？が重要になります。 そのため「プロトタイプ」と言いつつ考慮することが増えるので、TUIでそこまで操作性を必要としないClaude Codeにはない工数が一定かかると感じました。 アプリケションにもよりますが、プロトタイプでも「UIが使いにくいと評価しにくい場面」もあり、機能としては良くても「使いにくい」という事象が発生する場合があります。 僕自身のこの問題の対応方法としては、AIを使って複数のUIを並列で作成し、並べて比較する方法です。 並べることで「足りてなかった観点」にも気づけるので、「とりあえず作ってみる」という姿勢はどちらにせよ大切だと思いました。 2. アプリの利用やドッグフーディングの難しさ アプリによっては、常時自分たちで使わないアプリ（例えば、月に一回しか使わないプロダクトや、お客さんの限られたドメインでしか使わない場合）もあり、難しい所だと感じました。すぐにフィードバックが得られない場面もあると思います。 ただ、この場合でも「すぐ提供して一回リリースしてみる → 使ってもらう → 改良する」というループは重要なので、プロトタイプをまず作るという思考で開発を回すのが重要であることに変わりはないと思いました。 3. バグやコード品質とどう向き合うか？ 記事にも最後に触れられていましたが 、「バグやデグレとどう向き合うか？」は重要な課題かと思います。 Claude Codeでは、Anthropicの障害だけでなくClaude Code内部でのバグも発生している印象で、「今まで使えていたけど使えなくなった」という場面が多数ありました。 Claude Codeは利用ユーザーにとってバグがそこまでクリティカルではないですが、一つのバグが命取りになったり、すぐにユーザーが離れていくケースでは慎重にならざるを得ない場面も多くあると思います。 なので、コード品質を担保したり、デグレしないような仕組みをどれだけ作れるか？が重要だと感じました。 （ここはエンジニアの能力にも依存するので、エンジニアのスキルアップも必要だと思います） また、フロントエンドは一瞬でデグレして、かつ気づきにくい場面が多いので、特に気をつける必要があると思います。 コード品質や変更容易性は、今後より一層重要になると感じました。(口にするのは簡単ですが...) 日本の場合、バグには良くも悪くも敏感だと思うので、割り切る必要はありつつ、クリティカルなバグを出さずに開発スピードをどう上げていくか？が重要だと感じました。 とても勉強になる記事なので、気になる方はぜひ見てみてください！！

ちなみに！！！！ Anthropic公式のカンファレンス「Code with Claude」 実は東京🗼開催もあります！！！😳 日程は 6月10日🔥💪 Claude Codeの新情報や、 新機能のライブデモ、ハンズオン、 Claude開発チームとのセッションまで用意されています🤩 しかも、東京開催もライブ配信あり。 無料で視聴登録できます🔥 Claude Codeを ・これから触りたい人 ・すでに使い込んでる人 ・最新情報を追いたい人 これは見ておいた方がいいです。 東京開催の詳細はこちら👇 claude.com/code-with-clau… ライブ配信登録はこちら👇 claude.com/code-with-clau…

結局AIに作業やってもらいながら 色々質問するのが一番勉強になると思うんだよなぁ AI使うのも上手くなれるし

まあAIは本当に良いお手本になるよね

まあMCPの中でcli叩くのかなぁ

CLIをsandboxに入れること自体はできる。 ただ、本当に難しいのはそこではなくて、Claude Web上のsandboxで「認証情報をどう扱うか」だと思う。 ローカルCLIなら、OAuth tokenやrefresh tokenをユーザーのKeychainやローカル設定ファイルに保持できる。 でもWeb sandbox経由だと、 「そのtokenをどこに保存するのか」 「誰の権限として実行するのか」 「refresh tokenをどう安全に保持するのか」 「失効・監査・組織配布をどう扱うのか」 が一気に難しくなる。 エンジニア向けなら、環境変数にPATを入れる運用でも成立するかもしれない。 でもビジネスサイド向けにSlack / Notion / Google Drive / Jira / SalesforceみたいなSaaS連携を広げるなら、UIからOAuthで接続できて、権限管理まで含めて設計しやすいMCP Connectorの方が自然に見える。

みんな Skills や CLI 推しだけど、ビジネスサイド向けに展開して、さらに認証まわりまでちゃんと扱うなら、結局 MCP が強い気がしてきた。 MCP なら UI からもサポートされているし、セキュリティ的にも比較的安全に設計しやすい。 Skills も UI 設定はできるけど、Web クライアント前提だと、 「その CLI、どの sandbox にどうインストールして、どう安全に実行するの？」 という問題が出てきそう。 個人開発やエンジニア向けなら Skills / CLI は強い。 でも、ビジネスサイドまで巻き込むなら MCP が本命になりそう。

vercel エラーログまで見れるの楽すぎる

セコイアキャピタル「AI Asent 2026」 AI時代のプロダクト開発戦略 「MADフレームワーク」 ・M (Moats: 防壁) 　機能はMOATにならない。顧客のニーズにどれだけ深く入り込めるかが最大のMOAT ・A (Affordance: 容易性) 　どんなに強力なAIモデルでも、一般企業の従業員にターミナルは使いこなせない。直感的に「どう使えばいいか」がわかるような、ユーザーにとって最も抵抗の少ないシンプルな体験が重要 ・D (Diffusion: 普及) 　最先端のAI機能が生み出されるスピードと、一般企業がそれを導入するスピードの間には「大きな普及のギャップ」が存在しており、ここがアプリケーション層の企業にとっての大きなビジネスチャンスになる

@shun_aiLaboo おぉ！海外の生情報ありがとうございます✨ 既に実際にこの考え方で設計が行われてるんですね 海外で印象的な具体的な事例とかあったらぜひ投稿とかで共有していただけるとありがたいです☺️ フォローさせていただいたので楽しみに待ってます

@wk__2023 まさにそれですね。海外だと「AI-native」の設計思想が広がってて、「ユーザーの課題×最適なクライアント」で考えるのが基本です。Claude CodeはCLIベースの開発者向け、ChatGPTはエンドユーザー向け、Slack/Teamsは社内ワークフロー組み込みって使い分けが海外でも定着してきてます

aiネイティブなアプリを作る考え方は 小難しい話ではなく 結局どんな課題を持ったユーザーが,どんな目的で具体的にどのクライアント (claude code?? claude?? chatgpt??slack?? teams??discord??)を利用し そのためには何が必要なのかを考えれば良い気がする

vercel cliめっちゃ便利やな 環境変数cliから変更できるし pullでenv.localを落とせる 地味に環境変数手動で管理するの大変だったから助かる

claude designのhtmlフォーマットは良いね 導線整理に使える

sunoで曲作ってみた おすすめの曲をご紹介します suno.com/s/JYhJAZnI8RZY…

AI駆動開発は、 Transformers → Diffusionへの思考の転換が必要。 Transformers：今までのLLMの主流。一度に次のトークンを予測しながら逐次生成する方式。 Diffusion：画像生成で注目された手法。最初はノイズだらけの全体像から、徐々に構造を明確にし細部を洗練させていく方式。 要は 「まず全体像を荒く作って、徐々に細部を詰めていく」という考え方。 AIにそのまま生成させると 「なんか納得いかない出力が出てくる…」と場当たり的に修正しがちだが、 それではTransformers的な思考のまま。 大事なのは、まず粗い全体像をDiffusion的に作ってから、 「ここが納得いかない理由は何か」 を言語化し、論理的に完成度を高めていくこと。 手書き（従来）のやり方だと ・外部情報の収集が不足 ・自分の知識だけで局所最適なコードを書く ・会議では誰も全体像を把握できず、ただ困惑して時間を浪費 結局 「何をやっているのか分からなくなる」のが常だ。 一方、AIをDiffusion的に使えば、一瞬で複数のシミュレーションを回しながら思考をまとめ、全体最適なシステムを構築できる。