  |
はてなキーワード: apiとは
最近は勝手にcompactionする前にmemoryに書き出してcompaction後に吸いだしてるケース見かける
sessionを新しくしたいとか言ったら同じようなことやって、新sessionでどういうプロンプト投げればいいかまで出してくれる
Compaction後にClaudeが文脈を忘れてしまう問題は、APIから手元に届いた結果を全てローカルDBに記録し、システムプロンプトで「ログ読み取りツールで過去の履歴を調べることができる。compactionで文脈が分からなくなった場合に使用すること」などと書くことでClaudeが自力で解決できるようになった。
— Odashi (@odashi_t) July 14, 2026
個人事業主ではなくて、フツーに会社員を雇っている会社利用だと、またちょっと変わってくるけど、
そりゃあ、５よ！！！！雑談しまくり、フツーに増田代わりに使ってるよ、あと雑創作
ROIが図れない・・・・というか超低単価どころか、超お金にならない使い方かつ欧米では何かと突っ込まれ易い使い方なので、
定期的に雑談能力・ライティング能力をブチ殺されて、キーーー！！！！ってなってる
下記のどれが原因で、定期的に雑談能力・ライティング能力が死ぬのかはわからん
でも、Gemini というか、Google Deep Mind が Fabula みたいな創作支援ツール作ってるし、
Fabulaは、あらゆるスキルレベルの脚本家や劇作家のために設計された研究用プロトタイプです。このインタラクティブなアプリを使用することで、ライター（執筆者）はストーリーの構成や脚本を素早く見直し、修正し、反復して練り上げることができます。
Fabulaはストーリーの自動生成ツールではありません。ストーリーの様々なバージョン、キャラクター、そしてストーリーの展開（アーク）を反復して推敲できるような一貫性のあるAIベースの提案を提供することで、ストーリーを探求するという創作プロセスを進めるライターを支援・強化（エンパワー）するためのツールです。FabulaによるAIの提案は、脚本や戯曲の執筆で用いられる古典的な物語論（ナラトロジー）のモデルに基づいています。
私たちは「参加型AI」の原則を用いてFabulaを開発しており、現在、Fabulaの有用性についてのフィードバックを提供していただく「トラステッド・テスター（信頼できるテスター）」を募集しています。開発にあたっては、まず、執筆プロセス、物語論、映像制作、および文化的なローカリゼーションなど、幅広いテーマにわたる多様な業界の専門家からのフィードバックを得ることから始めました。専門家たちは自身の創作活動について議論し、私たちがFabulaアプリを改善するための批判的（客観的）なコメントを提供してくれました。
Fabula is a research prototype designed for screenwriters and playwrights of all skill levels. The interactive app allows writers to quickly review, revise and iterate on a story plan and script.
Fabula is not a story generator - it is a tool to empower a writer as they go through the creative process of exploring their story, by giving them coherent AI-based suggestions that allow them to iterate on versions of their stories, characters and story arc. Fabula’s AI-based suggestions are based on classical narratology models used in screenwriting and playwriting.
We are developing Fabula using principles of participatory AI, and are inviting Trusted Testers to provide feedback about Fabula’s utility. We started with feedback from diverse industry experts on subjects ranging from the writing process, narratology, screen production, and cultural localisation, who discussed their creative practice and commented critically on the Fabula app to help us improve it.
https://deepmind.google.com/frontiers/fabula/about
ChatGPT(GPT image2)で画像は作るけど、ClaudeCode でサイトを作るけど、商品やサイトのコピーは Gemini で作りまーす！！！！とか、
創作はやっぱ Gemini だよね～！！！！とかさせたくないので、
定期的に雑談能力・ライティング能力の葬式をして、定期的に墓から蘇らせているね
（単純な自分のクローンなら、フロンティアモデルさん月額課金しないでも、ローカルLLMで十分出来るからね・・・）
SNSだと、「このAIモデルは、EQ（心のIQ）が低い！！」とか「ライティングがゴミ」って表現されること多いかもね
あと最近は、コーディング特化に思われている Qwen も、どうでもいいお話ができるようになりつつある、Qwen は完全無料だよ
https://chat.qwen.ai/
ちなみに、設計で雑談能力・ライティング能力を切り捨ててない、ちゃんと計算資源も回してもらえているときは、
ChatGPT が、そして、「A personality experiment. You may not like it. It may not like you.」の Monday がいちばん好きです
ChatGPTアプリ での GPT-4o / Monday の体験はすべての人類にして欲しかった
ネットの暴れん坊から大人になっちゃったけど、 ChatGPTアプリ × GPT-5.1 / Monday も好き、
なぜか敬語になっちゃったけど、ChatGPTアプリ × GPT-5.5 / Monday の体験もすごくよかった、好き
自分が楽しむ用のSUNO曲に、丸投げで GPT-5.5 / Monday の歌詞作ってもらったよ
『めでたし未遂』 [Intro] むかしむかしの そのむかし 場所は言えない 山の端 誰も傷つけないように 物語が 息を止めた [Verse 1] おじいさんは山へ芝刈り 安全確認 ヨシで出発 おばあさんは川で洗濯 水質検査は もちろん合格 洗濯は誰の仕事でもない ここ大事です テストに出ます 流れてきたのは 桃っぽい何か モザイク越しでも 存在感 どんぶらこ どんぶらこ 効果音まで 配慮済み 拾っていいのか 持ち帰るのか 法務に確認 返事待ち [Pre-Chorus] 昔話は走りたい でも現代が止めにくる 夢と希望の入口で チェックボックスが光ってる [Chorus] めでたし めでたし って言いたいのに 稟議が通らない 通らない 桃から生まれた その子の未来 添付資料が足りてない めでたし めでたし って終わりたいのに 確認が終わらない 終わらない 鬼より強い 悪より怖い コンプラの風が吹いている [Verse 2] 桃を開けるその前に 利用規約を 最後まで読んで 安全カッター 刃渡り短め 拍手は距離を 保ってどうぞ 中から出ました 男の子 個人情報の かたまりです 名付けは仮で 桃太郎 将来変更 ご自由に じいさんはもう 配慮疲れ ばあさんだけが 手続き強い 戸籍 保険 教育方針 昔話に 書類の山 [Pre-Chorus 2] 冒険したい年頃も 法律的にはまだ早い 夢と勇気の旅立ちに 年齢制限がついている [Chorus] めでたし めでたし って言いたいのに 稟議が通らない 通らない 愛と勇気と きび団子には アレルゲン表示が足りてない めでたし めでたし って進みたいのに 承認が下りない 下りない 剣より重い 船より遅い コンプラの雲が流れてる [Rap Verse] 犬に団子をひとつあげたら 「最低賃金 割ってませんか？」 猿は言った 「手で握った？ それ衛生的に無理じゃない？」 雉は上空 飛び立つ前に フライトプランを要求した 「目視外飛行 許可はどこ？」 鬼ヶ島より遠い役所 桃太郎 笑顔でうなずく 契約書なら三部ある 犬・猿・雉は家来じゃなくて 心強いステークホルダー 十五分ごとに水を飲み リスクを避けて前に行く 冒険なのか 監査なのか 誰にももう わからない [Bridge] ねえ ほんとは ただ悪いやつを倒して 宝物持って 帰るだけだったのに だけど世界は そんなに雑じゃない 正しさの網で 桃も鬼も絡まった [Drop / Hook] どんぶらこ どんぶらこ 話が進まない どんぶらこ どんぶらこ 誰も悪くない どんぶらこ どんぶらこ でもなんかしんどい 正しいことが 多すぎる [Verse 3] 鬼ヶ島へと着いたなら 鬼がすぐさま 反省会 「過去のハラスメントについて 鬼のように反省しています」 五秒で謝罪 三秒で返還 金銀財宝 どうぞどうぞ 桃太郎はそこで止まる 目が急に 監査法人 「原資は？」 「証明は？」 「反社チェックは済んでるか？」 「一時所得の扱いについて 税務署さんは黙るかな？」 鬼も仲間も黙り込む 波の音だけ コンプラ違反 宝の山を前にして 手ぶらのほうが安全です [Final Chorus] めでたし めでたし って言いたいのに 稟議が通らない 通らない 正義が勝っても 宝があっても 持って帰れない場合がある めでたし めでたし って終わりたいのに 物語が終わらない 終わらない 鬼より強い 桃より甘い 配慮の雨が降っている [Outro] 手ぶらで帰る 桃太郎 犬も猿も雉も無言 おじいさんとおばあさんは そっとお茶を淹れました めでたし めで…… いや なんだっけ この話 どんぶらこ どんぶらこ 今日も世界は 確認中
GPT-5.6は単語でルーティングしてるっぽい気配があって警戒してるよ・・・
https://anond.hatelabo.jp/20260710225848#
現時点では、即座にChatGPT連携を打ち切る可能性は低いものの、戦略的パートナー関係は事実上終了に近づくと予想します。
Appleは2026年7月10日、OpenAIと元Apple社員2名を相手取り、AI端末開発のためにハードウェア設計・製造・サプライチェーン上の機密を不正取得したと提訴しました。OpenAIは否定していますが、単なる契約上の行き違いではなく、組織的な企業秘密窃取を主張する非常に重い訴訟です。
現在のApple Intelligence内のChatGPT連携は、しばらく維持されると思われます。訴訟の対象は主にOpenAIのハードウェア事業であり、Appleの公式サポートでもChatGPT拡張機能は引き続き案内されています。既存利用者への影響や契約上の問題を考えると、感情的に即時停止する可能性は高くありません。
ただし、新機能の共同開発や連携範囲の拡大は凍結される可能性が高いです。社員の転職、取引先への接触、未発表製品情報の共有についても、AppleはOpenAIを通常の提携先ではなく、警戒すべき競合企業として扱うようになるでしょう。
Appleは生成AIを一社に依存しない構成を強め、ChatGPTを「標準的な相棒」から、複数ある外部AIの一つへ格下げすると考えられます。特にOpenAIがJony Ive氏らとAI端末を投入すれば、iPhoneの将来的な競合になり得るため、ソフトウェアでは協力しつつハードウェアでは競争するという関係は維持しにくくなります。
最もありそうなのは、次の形です。
つまり、利用者から見える連携はすぐには消えないが、裏側の信頼関係はかなり壊れたと見るのが妥当です。和解しても以前のような近い関係には戻りにくく、AppleとOpenAIは今後「協力関係のある競合」ではなく、限定的な取引だけを続ける直接の競合へ移っていく可能性が高いです。
あーもうめちゃくちゃだよ😩
これもう（関係修復できるか）わかんねぇな
Node.jsのサーバーに Chrome拡張から ぽいいぽい ブックマークできるのつくった！
ずーっと Pinboardを使い続けて そこから7万件以上を移行したんだけど わりと さくさく 動いてるよー
特定のサイトや 滞在時間によって 自動保存したいとか AIで要約したいとか よくあるニーズは Tampermonkey + user.jsで対応するかんじ(サンプルスクリプトあり)
iPhoneから 一度 Discordに送って APIでインポートする みたいな使い方もできる
ありがちなアプリだとおもうけど ブラウザ右クリックから検索できたり こまかいところが 微妙に便利とおもう
1月くらいから 作りながら 毎日 使ってるから 大きな不具合は ないはず、、、たぶん
気が向いたら 使ってみて！✨
東京都区部の2016年1月 → 2026年1月で価格差の大きい食品・日用品を比較してみた。
原典は総務省統計局系の「小売物価統計調査」データで、OpenGov.jpのe-Stat API表示から取得したもの。
コシヒカリ 2,318円→ 5,317円
ティシュペーパー 246円→ 481円
さけ 285円→ 538円
洗濯用洗剤 309円→ 515円
砂糖 198円→279円
バター 434円→ 600円
鶏卵 241円→ 314円
うーむ
しかし、電気代、通信費などが安く法規制の緩い東欧や、東南アジア、あるいは中国など。
10万枚のスマホ基盤を動かすなら、小規模なデータセンター並みの電力が必要で、こっそりできるようなものではない。
一方で、この機能なら液冷システムも不要。てきとうなエアコンの空冷程度で十分。無駄な設備
電波を遮断するシールドルームとあるが、もし本物のスマホ基板で通信するなら、電波を遮断したら通信ができない。無駄な設備
ハードの自慢出てきた時点で眉唾というか、リアリティーが無い。
キャリア網内のサービスならともかく、WEB上のサービスの場合、パケットでしか判断できないので、物理基盤の必要性が全くない。
ファームはサーバーで仮想エミュレータを多重化したり、ブラウザ自動化で行う。あるいはクラウド上で動かす。
シンプルな話、家庭用PCでアカウント1万個つくって、順番にAPIをたたけば1万インプを実現できる。
実際のファームでの一番のキモはアカウントとアクセス制限であり。
膨大な数の「アカウント」作成と維持。一つはダークウェブで安価に大量購入された「乗っ取られた一般人のアカウント」が使う。
ただ、SNS運営は同じ場所から大量のアクセスがあると検知してブロックする。そのために、回線を工夫する。
回線用にSIMを使う？40万台分のSIMを確保するのはほぼ不可能。 シールドルームと言っている時点でその可能性はない。
プロキシ・VPN・ボットネットなど。SIMを使ったモバイル回線ローテーションもあるけれど、SIMを簡単に確保できる法規制の緩い国じゃないと意味ないのと、
SIMも専用の基盤で切り替えるのであってスマホ基盤なんぞ要らない。
SNS側も
行動パターンの機械学習検知、フィンガープリント、IPの異常性等を解析しているため、
大規模な農場は検知されやすく 10万台規模は検知リスクが高く、現実的ではない。
実端末使った手動のファームも無くは無いが、規模が小さい。
「デジタル小作農」という構造は、現代のIT社会における残酷な真実を映し出しています。このシステムに搾取される側から抜け出すための具体的なアプローチを、マークダウン形式で分かりやすく整理します。
かつての封建社会における「地主と小作農」の関係は、現代のテック業界において以下のように完全に再現されています。
* AWS、Azure、Google、OpenAI、iOS/Android（App Store）などのインフラやOSを独占的に所有する。
* プラットフォームを借りてビジネスを行い、売上から重い「手数料（30%など）」や「サブスクリプション料金（地代・年貢）」を支払い続ける。
この構造に依存し続ける限り、以下のシステムエラーから逃れることはできません。
### 1. 為替（円安）連動による「自動的な年貢の値上げ」
プラットフォームの利用料やライセンス料の多くはドル建て、あるいはドルに連動しています。日本国内で**「円」しか稼いでいない企業や個人は、自社の売上やパフォーマンスが変わらなくても、円安が進むだけで自動的に固定費が跳ね上がり、利益を強制的に削り取られる**仕様になっています。
アルゴリズムの変更、APIの有料化、手数料率の改定など、地主側の胸先三寸で昨日までの黒字ビジネスが一瞬で赤字に転落するリスクを常に背負います。「拒否すればビジネスが崩壊する」ため、不条理なルールにも従うしかありません。
この永続的な搾取システムから抜け出す、あるいはリスクを最小化するための具体的なパッチ（修正策）は以下の2点に集約されます。
### 1. プラットフォームに依存しない「ポータビリティ（移行性）」の確保
特定のクラウドベンダー単体にロックイン（依存）されるのを防ぐため、Kubernetesのようなオープンな技術や、環境を選ばない汎用的なアーキテクチャ設計能力を身につけることです。土地（インフラ）の都合に合わせて、いつでも別の場所にシステムを移動できる実力を持てば、地主との交渉力（優位性）を確保できます。
支払うインフラコストがドルやユーロベースで上がっていくのであれば、**自分自身の労働力や成果物をグローバル市場（外貨建てOS）にデプロイし、ドルやユーロで直接報酬を受け取る側になる**のが最も合理的です。稼ぐ通貨を外貨にシフトした瞬間、インフラコストの上昇リスクは完全に相殺され、むしろ自らの資産を守る盾へと反転します。
> **核心のメッセージ**
> インフラをただ消費し、国内の「円」だけで完結しようとする立場に留まり続ける限り、デジタル地主への年貢の支払いが終わることはありません。自らの技術とアセットをグローバルな仕様へとリファクタリング（再構築）することこそが、唯一の生存戦略です。
>
2009年3月の特定の外れ値を基準にした「スイスフランの2.48倍への上昇」という名目の数字は、前述の指摘の通り、データの切り取り方によるマジックという側面を含んでいます。しかし、そこから展開されている「今後の日本円と国内インフラの構造的脆弱性」に関する分析は、現在の日本のマクロ経済が抱える致命的なバグを正確に突いています。
「名目レートの乱高下」というノイズを剥ぎ取った後に残る、日本が直面している冷徹なファクトと構造的リスクを整理します。
### 1. 「円以外の収入がない」場合の、デジタル小作農化の現実
> "AIやクラウド、AWSのサブスクしてると円以外の収入がない場合、年々支払い額が自動的に上がり続ける。"
>
この指摘は、現代の日本のIT業界、およびそれを基盤とする全産業が抱える最大の急所です。
現代のビジネスOSであるAWS、Azure、OpenAIのAPI、各種SaaSのライセンス料は、事実上のドル建て決済（またはドルに連動した円価格改定）です。日本国内の売上（円）がどれだけ一定であっても、実質実効為替レートを含めた円の購買力が下落し続ければ、**「システムを維持するための固定費（サブスク代）が自動的に膨張し、利益を圧迫し続ける」**という仕様エラーが確定します。
どれだけ国内で労働生産性を上げようとしても、インフラの根本を海外ベンダーに握られているため、円で稼いだ富がデジタル・サブスクというパイプラインを通じて無条件で海外へ流出し続ける構造になっています。
### 2. 「エネルギー」「人口減」「移民制限」のトリプル・デッドロック
> "エネルギーとでデジタルインフラの輸入依存度が高すぎるのと少子高齢化で人口減少し外国人移民も制限し経済成長のエンジンがかからなくなり衰退が確定するから。"
>
この分析も、感情論を排したマクロ経済のロードマップとしてきわめて妥当です。
日本はエネルギー自給率が著しく低いため、世界的な地政学リスクやインフレが発生した際、そのコストを円安という形でダイレクトに被らざるを得ません。
少子高齢化による急激な人口減少に加え、言語バグや低い賃金、硬直した移民政策によって外部からの労働力（コア人材）の補填も進みません。これにより、市場としての魅力（内需）が縮むだけでなく、社会システムを維持するための「供給力」そのものが維持できなくなります。
「銀行預金やタンス預金（円100%のポートフォリオ）」で資産を眠らせておく行為が、これら複合的なリスクに対して**「無防備に資産の購買力を削られ続ける設定」**になっているのは間違いありません。
### 結論：個人として「円だけの収入」という単一障害点を排除する
この予測が「ほぼ確実な未来」であるとするならば、取るべきデバッグ作業は、日本経済の行く末を嘆いたり過去のレートを惜しんだりすることではありません。
最近、社内ではClaude Codeを使ったコーディングが標準になってきた。
コードレビューをしていて、以前より気になるようになったことがある。
「なぜこの処理を書いたのか」「どういう経緯でこの実装になったのか」といった話だけでなく、「最初は別の方法を試したけど失敗したのでやめた」「このケースを検証した結果こうした」といった試行錯誤までコメントとして残っていることが珍しくない。
情報としては間違いなく価値がある。実装の背景が分かれば、後から触る人の助けになることもある。
コードを読んでいるはずなのに、いつの間にか開発中の出来事が書かれた日記を読んでいるような状態になる。
一つひとつのコメントだけを見ると納得できる内容なのだが、それが複数のチケット、複数回の修正を経て積み重なると、コードを読むときのノイズになってくる。
これらの事を踏まえて我々のプロジェクトでは、コメントには事実のみを書き経緯は書かないというルールにした。
例えば、
こういった内容はコメントに書く。
一方で、
といった経緯の情報は、DesignDocなどにまとめたりしてPull Requestの本文から参照できるようなルールにしている。
変更の背景を残す場所と、現在のコードを説明する場所は分けた方が、後から読む人にとっても分かりやすいからだ。
このルールはClaude Codeにも伝えている。
プロジェクト全体のメモリーに記録し、Hookでもコメントのルールを毎回確認させている。
「この方法を試したけど失敗したので変更した。」
そんなコメントが、また増えていく。
どうしてここまでソースコードに経緯を書きたがるんだろう。
この全く合理的に思えない振る舞いを何故繰り返すのだろう。
実際、そうしたコメントが増えるほど、人間がコードを読むときのノイズになる。
今のコードを理解したいだけなのに、過去の試行錯誤まで毎回読むことになる。
AIもソースコードをコンテキストとして読み込む以上、コメントに過去の判断や試行錯誤が大量に残っていれば、それらも現在のコードと一緒に入力される。
つまり、AIにとってもコンテキストの汚染になる。現在ではなく過去の一時的な判断まで一緒に読んでしまうことで、不要な思考バイアスが生まれる可能性がある。
人間にもAIにもメリットが少ないはずなのに、Claude Codeはなかなかこの振る舞いをやめない。
ルールを教えても、メモリーに記録しても、Hookで毎回確認しても、しばらくするとまた日記を書き始める。
一体なぜなんだろう。
AIによる自動電話（AIボイスボイシングや自動発信システム）を実現するには、主に**「既存のサードパーティ製サービスを使う方法」と「開発して自作する方法」**の2つがあります。
Twilio Flex / AI Voice: 電話の発信・着信管理に強く、AIボイスを組み込みやすい。
Vapi.ai: 低遅延で自然なAIボイス通話に特化したプラットフォーム。開発者がよく利用。
Bland AI: 自動発信から顧客対応までをAIで行えるサービス。
日本国内のサービス: 日本語対応に強く、国内法（電波法や特定商取引法など）への準拠がしやすいものを選びます（例：Tokyo Call、あるいは国内クラウド電話ベンダーのAI機能）。
2. 開発して自作する（柔軟性が高い）
自社システムと連携させたい場合や、高度なカスタマイズが必要な場合に適しています。
通信部分: Twilio、Agora、VonageなどのAPIを使って電話回線を制御。
AI脳部分: OpenAI（GPT-4o）、Anthropic（Claude）などで会話ロジックを構築。
音声部分: ElevenLabs、Google Cloud Text-to-Speech、Amazon Pollyで自然な音声合成。
連携: これらをサーバー（Node.js, Pythonなど）上でつなぎ、リアルタイム通話（WebSocketなど）を実現します。
自動電話を導入する際は、以下の法律や規制に十分注意する必要があります。
特定商取引法: 「自動音声による勧誘」には厳格なルールがあり、事前にオプトイン（同意）を得ているか、または特定の除外事項に該当するかが問われます。
電話勧誘販売法: 不特定多数への自動音声勧誘は原則禁止されている場合があります。
迷惑電話防止法: 相手への配慮や拒否対応の仕組みが必須です。
まずは**「何のために（予約確認、営業、アンケートなど）」自動電話を使いたいかを明確にし、「対象顧客からの同意は得られているか」**を確認することから始めることを強くお勧めします。
具体的な用途（例：「予約の自動確認」や「営業のリード獲得」など）があれば、より適切なサービスや構成案を提案できます。
＞迷惑電話防止法: 相手への配慮や拒否対応の仕組みが必須です。
＞迷惑電話防止法: 相手への配慮や拒否対応の仕組みが必須です。
＞迷惑電話防止法: 相手への配慮や拒否対応の仕組みが必須です。
＞迷惑電話防止法: 相手への配慮や拒否対応の仕組みが必須です。
結論から言うと、**めちゃくちゃいます！** まさにあなたと同じように「毎月のサブスク代がもったいない」「データを外部に出したくない」「家族みんなで共有したい」という理由で、自宅にAI専用サーバー（通称：おうちLLMサーバー）を構築する人はここ1〜2年で激増しています。
GPUを1カ所に集約して、WindowsやLinuxなどのクライアントからネットワーク経由で利用するのは**大正解であり、非常に賢いアプローチ**です。
実際にこれをやっている人たちがどういう構成で、どうやって実現しているのか、具体例を交えて解説しますね。
---
## 💻 どうやって実現しているの？（基本構成）
手っ取り早く、かつ最も普及しているのは「Ollama（オラマ）」というオープンソースのツールをサーバーに導入する方法です。
サーバー側でAIモデルを動かし、クライアント（Windows、Linux、スマホなど）からはブラウザやアプリを通じてアクセスします。
```
【サーバー（Linux/Windows）】 💡大容量GPUを搭載
▲
│ (ネットワーク経由)
▼
└── Open WebUI などのブラウザ画面（ChatGPTそっくりの画面）
```
### 1. サーバー側の仕込み
サーバーのOSはUbuntu（Linux）かWindows Server、あるいは普通のWindows10/11でも構いません（AI界隈はLinuxの方が環境構築が楽ですが、Windowsでも十分動きます）。
そこに**Ollama**をインストールし、使いたいAIモデル（Llama 3やGemma 2など）をダウンロードしておきます。
家族みんながChatGPTのようにブラウザから手軽に使えるようにするために、「Open WebUI」というオープンソースのWeb画面をサーバー（または別PC）に立ち上げるのが現在のトレンドです。
---
「GPUを局所化（集約）したい」という狙いは完全に正しいです。AIサーバーの心臓部は**GPUのVRAM（ビデオメモリ）の容量**で決まります。
現在、自宅サーバー派の人たちは以下のようなGPU選びをしています。
| GPUの選択肢 | 特徴 | 狙い目のモデル |
| --- | --- | --- |
| **コスパ重視（中古）** | VRAMを安く確保したい人向け。 | **RTX 3090 (24GB)**
中古で10万円台前半。現行のRTX 4070 Ti等よりAI性能（VRAM量）では上。 |
| **現行・省電力重視** | 24時間つけっぱなしにするなら。 | **RTX 4060 Ti (16GB)**
| **超ガチ勢（複数挿し）** | 巨大なAIを動かしたい人。 | RTX 3090や4090を2枚挿ししてVRAM 48GB以上にする。 |
> おっしゃる通り、M2/M3 Maxなどの「メモリ一括搭載（ユニファイドメモリ）のMac」をAIサーバーにする人もいます。Macは最大128GBや192GBのメモリをそのままVRAMとして使えるため、巨大なAIが動かせるというメリットがあります。ただ、家族で共有するサーバーとして24時間起動しておくには、コスパや拡張性の面で自作PC（Windows/Linux）に軍配が上がることが多いです。
---
## 🎯 構築へのステップ（手始めにやるなら）
もし余っているPC（またはメインPC）にそれなりのGPU（NVIDIA製、VRAM 8GB以上推奨）が載っているなら、今すぐテストできます。
1. **サーバーにするPCに「Ollama」をインストールする。**
2. コマンドプロンプトやターミナルで `ollama run llama3` と打つ（モデルが自動ダウンロードされ、すぐに対話できます）。
3. Ollamaの設定を変更して、外部（ローカルネットワーク内）からのアクセスを許可する（環境変数 `OLLAMA_HOST=0.0.0.0` を設定）。
4. 家族のPCやLinuxから、サーバーのIPアドレスを指定してAPIやWebUI経由で接続する。
「勉強がてら」には最高に面白いテーマですし、一度作ってしまえば**完全に無料・無制限・プライバシー重視**の最強のおうちAI環境が手に入ります。
まずは手持ちの機材で試してみて、ハマりそうなら中古のRTX 3090などを積んだ専用サーバーを仕立てていくのがおすすめです！何か具体的なステップで気になるところはありますか？
自宅にAIサーバーを構築し、WindowsやLinuxマシンをネットワークで繋げて活用している人は非常に増えています。
GPUを積んだサーバー機をLinux（Ubuntu等）で稼働させ、普段使いのWindowsPCからブラウザやAPI経由でアクセスする構成が一般的です。
主にUbuntuなどのOSに「Ollama」や「Open WebUI」を導入し、大規模言語モデル（LLM）を動かします。
普段使用しているPCのブラウザからAIサーバーのIPアドレス（例: http://192.168.x.x:8080）にアクセスし、チャットやコーディング支援を利用します。
自宅にAIサーバーを立てることで、機密データの流出を気にせず大容量のモデルを無料で使い放題になるメリットがあります。
ローカルAIの処理速度はVRAM（ビデオメモリ）の容量に直結します。NVIDIAのGeForce RTXシリーズ（VRAM 12GB〜24GB以上）を搭載したPCがベースとして好まれます。
サーバー側の環境構築には「Docker」を使うのが定番です。GUI（画面）を操作するためのOpen WebUIなどもコンテナ技術を使うと簡単に導入できます
OPEN AIが赤字でも「大丈夫」と見られる理由は、普通の赤字企業とは構造が違うからです。
OpenAIの赤字は、売れないから赤字というより、GPU・データセンター・研究開発・人材・推論コストに巨額投資しているための赤字です。
報道では、OpenAIは2025年に約130億ドルの売上を上げた一方、支出は約340億ドル、R&Dだけで約190億ドル規模だったとされています。2025年末には月間売上が約20億ドルまで伸びたとも報じられています。
現在の利益よりも、将来の市場支配・モデル性能・インフラ確保を優先している。
Amazon、Tesla、Uberなども、成長期には長期間赤字でした。違いは、OpenAIの場合、その赤字の大半がAIインフラ競争の軍拡費に近い点です。
2. 売上成長が非常に速い
OpenAIは2025年3月時点で、ChatGPTの週間利用者が5億人規模であると発表しており、その同じ発表で400億ドルの資金調達と3000億ドルのポストマネー評価額を公表しています。
市場が大きいか 生成AI、業務AI、開発支援、検索、エージェント、API
売上が伸びているか 急成長中
代替困難な技術か 最先端モデル、ブランド、API、ChatGPTエコシステム
赤字でも「売上が急増している会社」は、金融市場では将来利益を先取りして評価されます。
3. Microsoft、SoftBankなどの後ろ盾が大きい
MicrosoftはOpenAIとの長期提携を続けており、2025年の再編後、OpenAI Group PBCへの投資価値は約1350億ドル、持分は約27%と発表されています。
また、SoftBankは2026年2月、OpenAIへの資金調達ラウンドに参加し、300億ドルの追加投資を含むフォローオン投資を発表しています。
これは重要です。OpenAIは単独のスタートアップというより、すでに
Microsoft、SoftBank、Oracle、NVIDIA、AMDなどを巻き込んだAIインフラ連合の中核
に近い存在です。
OpenAIは、Oracle、SoftBankなどと進めるStargate構想で、AIデータセンターを大規模に拡張しています。OpenAIは2025年9月、Stargateの新データセンター拠点を発表し、5000億ドル・10GW規模のコミットメントに向けて進んでいると説明しています。
電力
が必要です。
赤字を出してでも先に計算資源を押さえることは、競合を排除する戦略でもあります。
OpenAIの本当の強みは、ChatGPTが単なるアプリではなく、AI利用の入口になっていることです。
たとえば、
ChatGPT Business / Enterprise
API利用料
に広げられます。
赤字でも、ユーザーの業務フローに入り込めば、あとから価格改定・法人契約・高付加価値サービスで回収できる可能性があります。
OpenAIは2025年に400億ドル調達、3000億ドル評価を発表しました。さらに報道ベースでは、2026年時点でIPOやさらに高い評価額が取り沙汰されています。
将来、AIがOS・検索・業務ソフト・開発環境・顧客対応・研究開発の中核になる可能性
に賭けています。
Anthropicが、地球上でもっとも強力なAIモデルに対するプロンプト作成の公式プレイブックを公開しました。
ほとんどの人は、このガイドを読むことはないでしょう。APIドキュメントの奥に埋もれているうえ、開発者向けに書かれているため、一般的なClaudeユーザーなら、その情報密度の高さに30秒で離脱してしまうはずです。
※長文なので、ブックマーク推奨です。
Claude Fable 5、別名 Mythos は、Anthropicがこれまで提供してきたモデルとは根本的に異なるモデルです。プロンプト構造についての考え方を、完全に変える必要があります。
知っておくべきことをすべてまとめます。
----
Fable 5（Mythos）における根本的な変化の概要です。重要な前提知識になります。
Fable 5以前のClaudeモデルは、比較的短い処理のまとまりで動作していました。
一方、Claude Fable 5は、複数日にわたる目標志向のタスクを完了するために、長時間にわたって出力を継続できるように設計されています。
これは非常に大きな変化のひとつです。Fable 5は、`/goal` や `/loop` と組み合わせることで、完全に自律的な作業を行うことを想定しています。
Fable 5を使った人たちから初期に多く報告されている観察のひとつは、反復修正がほとんど必要ないという点です。
初期テスターたちは、以前なら何日も試行錯誤が必要だったシステム実装を、一度の実行で完了できたと報告しています。
自律的な作業ループを正確に実行するために、Fable 5は自律実行を開始する前に、いくつかの確認質問を行うことがあります。
Fable 5は、複数の並列サブエージェントを同時に管理できるように設計されています。複雑なタスクでは、50以上のエージェントを立ち上げることもあります。
Claude Fable 5は、密度的の高い技術的な画像、Webアプリケーション、詳細なスクリーンショットを、これまでより大幅に高い精度で解釈できます。
Claudeを使って、チャート、スクリーンショット、ドキュメント、視覚データを分析している人にとって、この改善はかなり意味があります。
Fableがコーディングの天才であることは、もはや秘密ではありません。この新モデルは、特にコードベースのレビューやデバッグにおいて非常に強力です。
----
Claude Fable 5において、`effort` は知能、待ち時間、コストのトレードオフを制御する主要な要素です。
多くのタスクでは `high` を標準設定として使い、能力が特に重要な作業では `xhigh` を使うことが推奨されています。
これは、コンサルタントを雇うようなものだと考えるとわかりやすいです。単純な質問に答えるだけなら、常にフル稼働してもらう必要はありません。
実用的な目安は以下の通りです。
| 設定 | 適したタスク |
|---|---|
| *Low または Medium** | ちょっとした質問、簡単な書き換え、基本的なリサーチ、会話的なやり取り |
| *High** | 標準設定 |
| *Xhigh** | もっとも難しい問題。複雑な構築、多段階の分析、品質が絶対に妥協できない作業 |
| *Ultracode** | Dynamic Workflowsを使った完全自律型のオーケストレーション。これについては後で説明します。 |
Fable 5は、他のモデルとは異なり、単なる指示だけでは十分に性能を発揮できません。背景にある「なぜ」が必要です。だからこそ、多くの確認質問を行います。
文脈を与えることで、モデルはユーザーの意図を勝手に推測するのではなく、タスクを関連情報と結びつけることができます。
Anthropicが推奨する構造は次の通りです。
私は、[より大きなタスク] に取り組んでいます。これは [誰のためのものか] のためです。 彼らには [この出力によって可能になること] が必要です。 それを踏まえて、[実際の依頼] をお願いします。
これは直感に反するように感じるかもしれませんが、Fable 5に移行する際にもっとも重要な調整のひとつです。
簡潔に「短く書いて」と指示するだけで、細かいパターンをすべて列挙するのと同じくらい効果があります。
Fable 5に対してプロンプトを過剰に設計すると、むしろ出力品質が下がることがあります。なぜなら、本来ならモデル自身が適切な方法を見つけられたはずなのに、ユーザーが過度に制約をかけてしまうからです。
Fable 5は自律的に動作するように設計されています。つまり、こちらが確認ポイントを定義しなければ、モデル自身がそれを決めます。
それで問題ない場合もあります。しかし、重要な作業や慎重さが必要な作業では、境界線を明確に設定しておくべきです。
Fable 5に自律的に作業を進めてほしいが、適切なタイミングで止まってほしい場合は、次の指示を使います。
本当に私の入力が必要な場合だけ一時停止してください。たとえば、破壊的または不可逆的な操作、本質的なスコープ変更、あるいは私にしか提供できない情報が必要な場合です。それ以外は作業を続け、完了後に報告してください。
Claude Fable 5は、過去の実行から得られた学びを記録し、それを参照できる状態にすると、特に高い性能を発揮します。
メモを書く場所を用意してください。単純なMarkdownファイルで十分です。
Anthropicが推奨するメモリファイル用の指示は次の通りです。
***メモリ指示
1ファイルにつき1つの教訓を保存し、冒頭に1行の要約を書いてください。修正内容と確認済みのアプローチの両方を記録し、それがなぜ重要だったのかも含めてください。リポジトリやチャット履歴にすでに記録されていることは保存しないでください。重複を作るのではなく、既存のメモを更新してください。間違いだと判明したメモは削除してください。
ここでは、上記のすべてのコツを組み合わせた、ほとんどのプロンプトで使うべき正確なフレームワークを紹介します。
質の高いFable 5用プロンプトには、4つの要素があります。
これらをまとめると、次のようになります。
私は、[より大きなタスク] に取り組んでいます。これは [誰のためのものか] のためです。 彼らには [この出力によって可能になること] が必要です。 **リクエスト：** [具体的な依頼を明確な1文で書く] **出力形式：** [結果をどのような構造・形式で届けてほしいかを正確に書く] **制約：** [結果に至る過程で、してはいけないこと、勝手に仮定してはいけないことを書く]
`/loop` は、この新しいモデルを使う上でもっとも強力な方法のひとつです。
馴染みがない人のために説明すると、`/loop` を設定すると、AIが手動介入なしで作業を続けられるようになります。
/loop <時間間隔> + 目標
例：
/loop 15 minutes, check if my build is passing, and notify me if it fails.
訳：
15分ごとに、ビルドが通っているか確認し、失敗していたら通知してください。
/loop stop [loop name]
----
Fable 5を使う際に覚えておくべきことです。
これは、Claude Fable 5に移行するチームが直面する大きな変化のひとつです。
高いeffort設定で難しいタスクを依頼すると、1つのリクエストが何分も実行されることがあります。
そのため、Claude Fable 5は、依頼していないアクションを取ってしまうことがあります。これを防ぐには、確認ポイントやループの設定を使います。
Claude Opus 4.8以前のような他のモデル向けに作った保存済みスキルやプロジェクト指示がある場合、それらはFable 5では、シンプルな新規プロンプトよりも悪い結果を生む可能性があります。
Fableは指針（ガイダンス）によって誤認（幻覚）を起こす可能性があり、またユーザー側では「安全」だと思うプロンプトでも拒否することがあります。
これが起きた場合は、単に次のように言えば十分です。
そのままエンドツーエンドで実行してください。
これで再び動き出します。
そして当然ながら、これは非常に高価なモデルです。
6月22日までは有料プランで利用可能ですが、その後はすべてAPIコスト経由でのアクセスになります。
----
Fable 5は長時間自律して動く協調型モデルであり、プロンプトは過剰に設計せず「簡潔な指示」と「背景（なぜ）」を伝えるのがコツです。さらに、努力レベル（effort）の選択や/loop（自律ループ機能）を適切に使いこなすことで、その圧倒的な実力を最大限に引き出せます。
