こぎお

[coji 溝口浩二 @techtalkjp]

Created a community provider for Vercel AI SDK that integrates Claude Code.

Enables Claude MAX users to build local LLM applications using the standard Vercel AI SDK interface.

The provider was implemented with assistance from Claude Code itself.

https://t.co/UE4CWVkqiu

[Hatake | Ubie @rhatake_jp]

Y Combinator の最新話 "How To Design Better AI Apps" が、AI アプリの設計ですごい重要な指摘してたので翻訳・要約

3行サマリー

・現在、多くの AI アプリはユーザーの期待を満たせず、使いづらく感じられている。
・その主な原因は、従来型の開発手法をAIに適用し、プロンプトを隠した「ブラックボックス型の設計」をしていることにある。
・今後はユーザー自身が AI の振る舞いを理解し、カスタマイズできる UX 設計が必要である。

1. AIアプリが抱える課題

(1) ユーザー体験の二極化

開発者向け AI ツール（Cursor や Windsurf）は高度で使いやすく人気がある。

一方、一般ユーザー向けのアプリ（例：Gmail の AI 返信機能）は使いにくく、期待外れの結果を提供している。

(2) Gmail の具体例

Gmail の AI 返信機能は、「無難で形式的すぎる文面」を生成し、ユーザー個人の意図や口調を全く反映していない。

結果、AI 機能がかえって邪魔に感じられてしまう。

2. 問題の根本原因

(1) システムプロンプトがブラックボックス化されている

AI の挙動を決定する重要な「システムプロンプト」（AI への基本的な指示文）がユーザーから完全に隠されている。

これが個性のない、画一的で形式的な出力の原因になっている。

(2) 古い開発手法を AI にそのまま適用

AI アプリの多くは、従来のソフトウェア開発のプロセスをそのまま流用している。

従来型：『仕様決定 → UI 設計 → コードで機能を実装 → テスト → リリース』という一方向的な流れで設計。

Gmail の AI 返信機能を例にすると、開発者が「返信ボタンを押すと、AI が丁寧で社交辞令的な文章を生成する」と、予め固定したシステムプロンプトを書き込み、固定化された機能として実装している。

しかし、AI（LLM）の本質は「生成的で状況に応じて動的に振る舞う」こと。固定的な設計では、AI 本来の良さを発揮できず、結果として個々のユーザーにとって最適な体験が生まれない。

AI には「一方通行で機能を固定する開発」ではなく、「ユーザーが自由に AI を調整（teach）できるような仕組み」が求められている。

3. 解決策・具体的なアプローチ

(1) システムプロンプトの透明化とユーザーによるカスタマイズ

ユーザーが AI に与える基本的な指示（プロンプト）を見られる・編集できるUIを設計する。

例えばユーザーが「自分の個性的な文体に合わせて返信させる」といった細かな調整が可能になる仕組みを用意する。

(2) 開発の新しいパラダイムへの転換

「仕様 → 実装 → テスト」ではなく、「ユーザーがどのように AI を調整・育成できるか」を中心とした新たな開発アプローチを採用する。

特に非開発者でも自然言語を通じて AI を調整できるようにすることで、ユーザー自身が望む UX を創り出せるようになる。

4. 結論：これからの AI アプリ設計のあり方

AI アプリはユーザーにとってブラックボックスではなく、透明で調整可能な道具であるべき。

AI をユーザー自身が使いやすく調整できることが、継続的に使ってもらえる製品となるための重要な鍵である。

AI を通じて目的に適したユーザー体験を提供するには、設計の根本から見直しが必要である。

[Hi_Noguchi | 株式会社きみより代表 @Hi_Noguchi]

note 記事投稿しましたー

GitHub Copilot Coding Agent と Claude Code + GitHub Actions はどちらがどんな人向きか
https://t.co/bv7KSWAC7i

[ぱらどっぐ @PLTR_Dog]

パラ友各位

$PLTR が他のAI企業と一線を画す技術「Ontology」についてまとめてみました。
長文となりますが、お時間ある方はご一読下さい🐕
※ブックマーク推奨
$PLTR #palantir #パランティア #米国株

Ontology とは「データの意味を整理して、つながりを理解しやすくする仕組み」 です。

例えば、製造業の会社があるとします。この会社には「工場」「機械」「製品」「従業員」というデータが存在します。ただし、これらのデータは単なるリストとして存在するだけでは、関係性が見えません。

ここで Ontology を使うと、
▷「工場には複数の機械が設置されている」
▷「機械は特定の製品を製造する」
▷「従業員は機械の保守や点検を担当する」
といったデータのつながりを明確にすることができます。
その結果、「どの工場で、どの機械が、どの製品を作っているのか」をすぐに把握できるようになります。
また、ある機械が故障した場合、「その機械がどの製品の生産に影響を与えるか」「修理を担当するのは誰か」などの情報をすぐに導き出せます。

このように、Ontologyを活用すると、データが単なる表の集まりではなく、ビジネスに役立つ知識のネットワークとして整理されます。
ーーー

Palantir Foundry の Ontology は、企業が持つ大量のデータを整理し、現実世界の構造を反映したデータモデルを作るための仕組みです。

例えば、自動車メーカー を想定します。
このメーカーは世界中に工場があり、各工場でさまざまな車種を生産しています。さらに、各車両には数千もの部品が使われており、それらは異なるサプライヤーから調達されています。

このとき、Ontology を活用すると、
▷「工場ごとにどの車種を生産しているか」
▷「各車種に使われている部品の詳細」
▷「部品のサプライヤーと納入状況」
▷「部品の品質や不具合情報」
といったデータを体系的に整理できます。

これにより、例えば「ある車種でリコール（回収修理）が発生した」ときに、その車種に使われた部品が、どのサプライヤーから供給されたのか、どの工場で製造された車両に影響があるのか、影響を受ける顧客は誰か、といった情報をすぐに特定できるようになります。

Palantir Foundry の Ontology は、こうした複雑なデータの関係性を整理し、迅速な意思決定を支援する役割を果たします。
ーーー

ー他社の LLM との違いー
LLM（大規模言語モデル：Large Language Model）は、大量のデータを学習し、自然な言葉を理解し、生成するAI です。
例えば、OpenAI の GPT や Google の Gemini などが代表的です。

LLMは「過去のデータから最も可能性の高い答えを予測して生成する」ことが得意ですが、データの正確な関係性や、企業ごとのビジネスルールを整理するのは苦手 です。

一方、Palantir Foundry の Ontology は、LLMのように文章を作るのではなく、データの整理と関係性の明確化 を目的としています。

例えば、保険会社が 「顧客情報」「契約情報」「保険金請求」 などのデータを管理しているとします。
このとき、LLMに「Aさんが最近請求した保険金の内容を教えて」と質問すると、テキストデータを検索し、関連しそうな情報を予測して答えます。ただし、誤った情報を提示する可能性もあります。

しかし、Ontology を活用すると、
・Aさんの過去の契約履歴や請求履歴を正確に整理
・どの保険商品が適用されるかを明確に把握
・類似の請求案件と比較して不正請求の可能性を分析
といったことが可能になります。

つまり、LLMは「自由に文章を生成するAI」 であり、Ontology は「データを正しく整理して、ビジネスに活用する仕組み」 という違いがあります。
LLMは、あくまで「過去のデータから学習して推論する」ため、事実とは異なる答えを出す可能性がありますが、Ontology は「データの正確な構造を維持する」ことを目的としているため、企業が信頼できる情報に基づいて意思決定できるのが特徴です。

ーまとめー
Ontology は、データの関係性を整理し、意味を明確にするための仕組みです。
Palantir Foundry の Ontology は、企業が扱う膨大なデータを、現実世界の構造に基づいて整理し、正確で信頼性の高い情報管理を可能にします。

一方、LLMは自然言語の理解や生成に優れていますが、データの正確な整理や、業務ルールに基づいた管理は得意ではありません。

そのため、LLMと Ontology はそれぞれ異なる役割を持ち、組み合わせることでより高度なデータ活用が可能になります。
たとえば、Ontology で正しく整理されたデータをLLMが活用すれば、企業は「正確なデータに基づくインテリジェントな対話型AI」を構築できるようになります。

Ontology と LLM は対立する技術ではなく、補完し合うことで、より信頼性の高いデータ分析やAI活用が可能になります。

[d @d_1d2d]

DeepSeekに関してはAnthropic CEOがわかりやすい記事を書いているので、それだけ読めばOK。以下まとめ。
・「米国のAIリーダーシップが脅かされている」という見方は過大評価である
・AIの知能が上がるほど企業はコスト削減より高性能化のために投資を増やす
・コストが下がっても、その分をさらに強力なモデルを作るために再投入する
・「やがてAIが安くなる」という単純な見方は誤解で、性能追求のための投資は続く
・まだReasoningスケーリングカーブの初期段階で、新しい手法を導入すると少額で大きく性能を向上できる時期にある
・DeepSeekが米国企業より極端に安いコストで同レベルのモデルを作ったわけではない
・いくつかの技術的なイノベーションはあるが、騒がれているほどのことではない
・公平に言えば、「DeepSeekは米国のモデルより7〜10ヶ月ほど遅れた性能のモデルを、コストをかなり抑えて作った（ただし世間で言われるほど極端な比率ではない）」というくらいが正確な表現
・コスト削減カーブの中で想定通りの範囲なので、大きなブレークスルーではない
・大規模モデルの性能は上がり続けるが、依然として数十億ドル以上の膨大な資金が必要
・2026～2027年には「ほとんどの人間より優れたAI」が登場すると予想され、その開発には数百万枚のチップと数百億ドルが必要
・将来的に米国も中国も数百万枚のチップを手にできれば二極世界に、できなければ単極世界になる
・その鍵を握るのが厳格な輸出管理で、中国が大量のチップを入手できるかどうかを左右する
・DeepSeekは米国企業と比べても資金不足だったわけではなく、単に優秀なエンジニアを擁する競合企業である
・Nvidiaにとって悪いニュースではないはずで、株価下落は不可解
・R1モデルが注目を浴びたのはチェーン・オブ・ソートを表示するUIが理由であり、モデル性能そのものの革新ではない
・中国製チップはまだNvidiaの最先端チップに及ばず、生産能力も不透明なため需要を満たせていない可能性が高い

[Sho Yokoyama @yuzutas0]

大福帳（ワイドテーブル、OBT）は

・dimベースでfctを結合したdim wide
・fctベースでdimを結合したfct wide
×
・結合元の最小粒度で揃えた unit wide
・必要な粒度に集約した aggregate wide

の組み合わせで設計するのがお勧め。

例：顧客id×年月単位で行動ファネルや注文情報を結合したテーブル。

[OpenAI @OpenAI]

Announcing The Stargate Project

The Stargate Project is a new company which intends to invest $500 billion over the next four years building new AI infrastructure for OpenAI in the United States. We will begin deploying $100 billion immediately. This infrastructure will secure American leadership in AI, create hundreds of thousands of American jobs, and generate massive economic benefit for the entire world. This project will not only support the re-industrialization of the United States but also provide a strategic capability to protect the national security of America and its allies.

The initial equity funders in Stargate are SoftBank, OpenAI, Oracle, and MGX. SoftBank and OpenAI are the lead partners for Stargate, with SoftBank having financial responsibility and OpenAI having operational responsibility. Masayoshi Son will be the chairman.

Arm, Microsoft, NVIDIA, Oracle, and OpenAI are the key initial technology partners. The buildout is currently underway, starting in Texas, and we are evaluating potential sites across the country for more campuses as we finalize definitive agreements.

As part of Stargate, Oracle, NVIDIA, and OpenAI will closely collaborate to build and operate this computing system. This builds on a deep collaboration between OpenAI and NVIDIA going back to 2016 and a newer partnership between OpenAI and Oracle.

This also builds on the existing OpenAI partnership with Microsoft. OpenAI will continue to increase its consumption of Azure as OpenAI continues its work with Microsoft with this additional compute to train leading models and deliver great products and services.

All of us look forward to continuing to build and develop AI—and in particular AGI—for the benefit of all of humanity. We believe that this new step is critical on the path, and will enable creative people to figure out how to use AI to elevate humanity.

[Andrew Curran @AndrewCurran_]

Anthropic CEO Dario Amodei is in Davos.
- AI could surpass human intelligence in the next two or three years
- Anthropic will be running over 1 million GPU's by 2026
- voice mode incoming for Claude!
- better memory for Claude
- smarter models 'in the coming months'

[Nari @fukubaka0825]

全然違うのに言及してる人少なすぎて、ちゃんとコード読んだり使ってないのに比較するんだなぁと思ってたポイントだ
Clineはripgrepと一部tree-sitterでかなりシンプル、Curosrはsemantic searchとripgrepと諸々を適切に組み合わせて使っていたり、他のAI IDEもCode Searchは色々それぞれ工夫してる

[Kenn Ejima @kenn]

AIエージェントで自動化の話よく出るけどさ、イーロンマスクが良いこと言ってて自動化は最後のステップだって言ってるんだよ。

1. 今やってること自体がアホな事が多いからまずそれをヤメロ
2. やってることから不要なステップを削除しろ
3. 単純化して設計から見直せ
4. プロセスを加速せよ、ただし上三つが全部できてから取り組む
5. 最後に自動化、ただしここまできても早すぎるのは良くない

意味のない仕事を自動化してもゴミが増えるだけだもんね。本当に自動化が必要な仕事はこの世にほとんどないというのが真実たったりする

[坂本 祥二｜HQ CEO @shoji_hq]

元祖コンパウンド戦略の超急成長スタートアップRippling創業者Parker Conradのインタビュー備忘メモ。

「多くのB2Bソフトウェアのビジネスモデルは根本的に破綻している」という凄まじい発言もあり、食い入るように動画見てしまった。AIやFounder Modeに関する見解も非常に学びになった。

・多くのB2Bソフトウェア事業の根本的では、ビジネスモデルは破綻している。
過去5年で、上場B2Bソフトウェア企業は営業／マーケティングを50％増やしたが、獲得した売上／New ARRは10％下がっている。
企業数が増えすぎ、競争が激しくなりすぎている。これがコンパウンド戦略を支持する背景の一つになっている。
"Fundamentally the business model for a lot of software is just broken..."

・AIによって企業はより少数精鋭集団のように運営されるようになる。
AIによって、2000人企業は200人のように、200人企業は20人のように、運営されるようになる。たとえ会社が巨大になっても、CEOとCTOの深いディスカッションが、ひとりのEngineerの意思決定に影響を与えられるようになる。CEOやCTOは現場で何が起きているのかを正確に理解できないが、AIにはできる。

・AIによって、B2Bソフトウェアはカスタマイズされるようになる。
全ての企業は固有の独自のニーズをもっている。AIを使えば、特定の業界、ビジネス、ニーズに合わせて、ソフトウェアをより正確に構成できる。コードを書かずに、コードレスソフトウェア開発の本来の姿に戻れる。カンブリア爆発のようなあらゆるソフトウェアの爆発的増加が起こり、ソフトウェアは、カスタマイズされる。

・AIのInside Sales/SDRは機能していないし、将来も大きな期待は得られない。
AIは魅力的なヒントをくれるものの、実際にはうまく仕事ができていない。将来、それが反転し、彼らがそれをできるようになったとしても、人々が期待しているようなインパクトは得られない。「おぉ、すごい！これでセールスとマーケティングが楽になる！」というようなことは起こらない。なぜなら、人々がアウトバウンドが多すぎて圧倒され、チャネルとして機能しなくなるからだ。

・コンパウンド戦略をとることで他社が追随できない研究開発に投資できる。
コンパウンド戦略であれば、あらゆるソフトウェアに恩恵を与えられるため、分析、承認、自動化などの機能に大きな投資をして、最先端のソリューションにすることができる。

・Founder Modeは大きな問題が起きているときだけ機能する。
創業者モードであっても企業には優秀な重役が必要。会社を運営するには、人を採用し、経営を手伝ってもらう必要がある。ただし、何かが壊れている場合や、重要な問題がある場合に、創業者モードが機能する。トップダウンだけで問題を修正することはできない。問題の根本まで行き、サポートチケットを確認したり、営業電話を聞いたり、 問題を理解するまで、ある程度の期間、現場で仕事をするべき。ずっと下まで降りていくべき。

・PMFにおいては、うまくいかないアイデアは、すぐに諦めるべき。
世の中には、とにかく頑張れ、諦めるなというアドバイスがあるが、それは最悪なアドバイス。うまくいっていないことを軸にして、最終的にそれがうまくいくようにビジネスを転換するなんてことは、ほとんどない。Airbnbの話はいつも出てきますが、ほとんどの場合はそうはならない。アイデアを5つほど考えていたのですが、そのすべてが信じられないほどうまくいった。信じられないほどうまくいった。PMFとはそのように起こる。

[こぎお @corgiking06]

https://t.co/4ukgW4Awra

[💐aちゃん @honeya__150]

無印良品で買い揃えた防災グッズたち

[こぎお @corgiking06]

How Generative AI Is Remaking UI/UX Design https://t.co/xed1JaRA81

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

世の中の「仕事」の4割ぐらいは「フォーマット変換」なんじゃないかと思ってて、この仕事こそがLLMで一番なんとかできて人類のためになるジャンルだと思う。単純にファイル形式の変換という意味でもそうだし、slackで発散で会話してたログを仕様にまとめなおすとかもフォーマット変換だなと。
---
コンテンツ自体は特にAddされないけど、伝達するために「よしなに」伝えたい人にとって最適な形に変換するプロセス。まぁここの作業を自動化しちゃうと、どっかの記事でみたみたいに、余白が減って疲れちゃうというのはあるなーと思うけど、中身の議論に集中したいひとたちにとって、ここの変換プロセスこそが超効率化したいところで、ここの作業って下手したら評価されない分野だったりするし、自分でもそう思うから、早く中身のこと考えたいのにーとイライラしながらやってしまうことも多いので、まぁ減らすにこしたことはない。
---
自分の仕事で広い意味で「フォーマット変換」タスクだなーと頭によぎったときは、基本LLMでなんとかできないか、というのを考えるようにしてる
---
まぁしかしこれが意外と現時点では難易度高いから、つらいところなんですけどね。でも一度フォーマット変換フローを確立すると、その後なんどでもつかえるから、まぁ発生したら時間かけて考える価値はあるとおもっている

[しょーてぃー @shoty_k2]

月間アクティブユーザー数は約1,000万人を超えるPerplexity社が明かすAI時代の製品開発術についてインタビューが公開されていた。同社は設立からわずか2年足らずで、時価総額10億ドル超のユニコーン企業だ。急成長を支える独自の製品開発アプローチについて、同社の共同創業者でプロダクト責任者のジョニー・ホー氏によると、以下の4点だ。

1. AIファースト
製品開発のあらゆるステップでAIを活用。新機能のアイデア出しから、リリースまでの各フェーズで、AIに質問を投げかけることで、素早く適切な方向性を見出している。

2. 粘菌型の組織構造
プロジェクトを可能な限り並列化し、コーディネーションコストを最小限に抑えることを重視。各プロジェクトは、設計、フロントエンド、バックエンドが同時並行で進められる。

3. 小規模チーム
プロジェクトチームは2〜3人と小規模。同社の人気ポッドキャストは、わずか1人のスタッフが企画から制作まで手がけている。

4. 少数精鋭のマネジメント層
他者の仕事を導くことに長けた人材の採用は避け、自ら率先して動く個人貢献者を重用。現在、マネージャーの数は最小限に留めている。

ホー氏は「将来的には、技術に強いプロダクトマネージャーや、プロダクトセンスを持ったエンジニアが、企業にとって最も価値のある人材になるだろう」と予測する。

AI時代における新たな組織のあり方であろう。変化の激しい環境下で、いかに俊敏かつ効率的に価値を生み出していくかが問われている。

🔗https://t.co/dZ0O6OIuPG

[Aaron Levie @levie]

AI agents have the ability to fundamentally change the business model of enterprise software. Today, when you build a SaaS product, the primary business model is to sell seats that are tied to the end-users of your service. For "same store" sales, you can essentially grow at the rate of the headcount growth of that customer, or by adding additional capabilities on top of your offering. This business model is, of course fantastic, and has been around since the earliest days of enterprise software, and will keep going forever.

But AI Agents unlock an entirely new business model in software, because you can now grow in a way that is uncorrelated to direct enterprise headcount or even external factors to your software. What's amazing about this model is that the AI vendor actually can directly grow itself within an enterprise account due to direct productivity gains. 

For instance, imagine an AI Agent that can generate outbound sales demand for a startup. Traditionally, B2B companies will start by hiring a very small team of maybe one or two people, and increase resources in this area in a very incremental fashion -- essentially a process that looks like a guessing game where you try to predict how much demand there might be in the market, the ability to fund new resources, and the length of time it takes to hire great talent. In a world of AI Agents, you would simply set a budget and then decide how fast you want to grow. This is much closer to the business model of Google Adwords than it is of a traditional SaaS service.

The same would be true for entirely different functions, where AI Agents can develop software at the rate of how many software projects you want built or how many legal documents you want reviewed -- all unconstrained by a company's headcount. This will even happen in areas where you wouldn't initially expect demand levels to change just because you move to AI, but in fact where there's plenty of latent demand. For instance, in front-line support, in a world where AI Agents can answer a greater set of questions a customer might have, you could see the kind of interaction volumes going up far higher in a world of AI. 

This all has major implications to the economics of software, and it means that the AI Agent business model goes after a far greater pool of spend than just traditional IT. If software products now directly *drive* company productivity instead of just *enabling* company productivity, this could lead to a step-function change in the size of IT markets over time. Wild.

[古城 巧 🦜 経営管理AIエージェント“Zaimo.ai” CEO @kojotaku29]

Zaimo․aiを創業→BizDevをしていく上で必要かつ助かったリンク等を纏めたNotion Pageをせっかくなので外部公開しようと思います！
GW中に起業や事業の準備を進めようとしている方々はぜひご活用ください～！
https://t.co/Vglj1S3jpK

[LlamaIndex 🦙 @llama_index]

A 9-part series on RAG from Prototype to Production ⭐️

RAG in a notebook is easy, RAG serving live production users is hard. This tutorial series by Marco Bertelli is the perfect step-by-step resource to outline all the architectural components you need to productionize a full RAG server:

1. Introduction and setting up prototype RAG
2. Incorporating conversation history, user feedback, advanced RAG
3. Setting up the right document store for dynamic RAG
4. Building and deploying backend to Heroku with CI/CD
5. (Most recently) Building and deploying FE to AWS Cloudfront with ACLs on S3

Check out the latest tutorial which concludes this series - deploying FE to AWS and GitHub: https://t.co/L3inn3mcxJ

To start at the beginning, check out this tutorial instead: https://t.co/NrElgD3xY4

[Weijia Shi @WeijiaShi2]

🙋‍♀️How to present the same text in diff. tasks/domains as diff. embeddings W/O training?

We introduce Instructor👨‍🏫, an instruction-finetuned embedder that can generate text embeddings tailored to any task given the task instruction➡️sota on 7⃣0⃣tasks👇!

https://t.co/mD8UeVg4WE