  |
はてなキーワード:国産とは
---
日本の教育現場では、児童・生徒がスマホ・SNSを利用することでいじめ・犯罪・自傷リスクが増大。
高齢者や中年世代も、スマホOSの変化により操作が困難で、生活に必要な情報アクセスに課題。
端末・OS・アプリが海外企業中心で、国民全体の生活基盤としての安全性・安定性が不十分。
政府アプリ（マイナポータル）の普及により、国民が行政デジタルサービスに依存する状況が増加。
デジタル機器利用がほとんど**「米や野菜の次元」まで多用されていることを鑑み、教育端末・高齢者端末を国産基盤で統一し、安全・安心な情報圏を確立**する必要がある。
---
デジタル機器利用がほとんど「米や野菜の次元」まで多用されていることを鑑みて、OS／端末を国民に広く浸透させ、生活の基礎インフラとして安定供給する。
Google等の海外情報収集・広告モデルに政府が深く依存する状態を是正し、国内企業の技術・サービスを活用する。
LINE等国内企業製アプリのUI・UXを参考に、教育・高齢者向け端末の基本操作形態に転用。
マイナポータルと教育ポータルを連携させ、市役所・役場などの行政サービスへ安全にアクセスできる統一窓口を実現する。
いじめの「撮影→SNS拡散」を技術的に抑止し、第二次性徴期における心理的打撃を未然に検知・介入できる体制を作る。
中年・高齢者が既に慣れた操作感（ケータイ的操作）と、子どもの学習ニーズの双方を満たすUI/UXを提供する。
ネット遮断下でも安否確認・避難情報が機能する極小OSモードを整備し、国家レベルの迅速な対応を可能にする。
NECやLINE、国内スタートアップを連携させ、端末・OS・アプリの内製化・雇用創出を促進する。
情報利用の透明性（誰がいつ見たかの監査ログ）と、プライバシー・人権を尊重する利用ルールを制度的に確立する。
---
操作方法は「トーク画面・アイコン・通知方式」を教育・高齢者向けに最適化
3-2.ターゲット端末
---
LINE等国内製アプリUIを基本形として、教育・高齢者端末の操作性を最適化
TRON派生極小OS（Life-TRON）に移植する際もUI/UXの操作感を維持
互換レイヤーを用いて、Androidアプリも政府OS上で動作可能
4-2. サブフェーズ
OS設計・仕様確定政府OS基盤設計TRON系極小OSに国内UIを組み込み、教育・高齢者端末向け軽量UI・操作性を設計IPA、TRON協会、NEC、LINE
移行用互換レイヤー開発Androidアプリ継続利用 現行学習・連絡帳・SNSアプリを互換環境で動作。API/ID連携を政府OS標準に統合スタートアップ、NEC
教育端末・高齢者端末実証 実運用テストUI操作性、災害モード、ログ管理を確認教育委員会・自治体
ポータル・アプリ移行データ統合教育ポータル・学習アプリ・SNS・行政サービスを政府OSネイティブ化IPA、NEC、LINE、スタートアップ
全国展開・定着 完全移行Android端末は段階的にフェーズアウト。全国学校・高齢者施設で展開文科省・総務省・自治体
4. 段階的にネイティブ化・全国展開
---
5. 実行体制
大手企業（NEC・LINE）：端末製造・クラウド提供・UI転用
---
6. 次のステップ
----
「My Job Went ToIndia」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went toIndia :オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は2006年です。
かいつまんで話すと、インターネットが整備され、輸送コストがほとんどかからないソフトウェア開発では、アメリカのエンジニアは給与の面でオフショアに歯が立たない、だって、1/10の給与でインドのエンジニアは働くんだぜ？という本です。
そうした、価格競争力で負けるアメリカのソフトウェアエンジニアは、如何にして今後サバイブすべきなのか、という本になっています。
（普通に面白いしAIコーディング時代に通づるものがあるので復刊を希望したいところですが、まあ直球過ぎる題名を何とかしないと再販は無理でしょうな）
そして、JTCや外資問わず、過去にオフショア開発を経験された技術屋のみなさんははてブにも多く生息されているでしょう。
では、ジュニア開発者は不要になりシニア開発者のみになって、いまのソフトウェア開発は主に安い給与で働いてくれるところに遠隔で作業してもらって、レビューだけすれば良い環境ですか？
そうはなっていません。なぜでしょうか。
さて、今普通にXと連動する中古品売買プラットフォームを開発しようと思ったら、どうやってつくるでしょうか？
この文脈に埋め込まれたいくつもの情報「今」「普通」「連動」「中古品」「売買」「プラットフォーム」「開発」を解釈し、すり合わせ、未来の運営者も含めた全員に伝えるためのコストが、コミュニケーションコストです。
そうなると、「ちょっと良い感じにラフでいいからプロトタイプ作って持ってきてよ」で話が通じるのは、受注者マインドがしっかりした日本の受託開発現場の精鋭たちになるわけです。
テストケースだけを通過するように、内部テーブルを持たせた関数を大量に持ってこられてレビュー時に頭を抱えた経験が無いひとは、とても幸運なのです。
とは言え、これは何も文化の違いに起因するだけではありません。仕様とは、環境によって定まるものだからです。
例えば、うるう年判定の関数は、1581年以前をエラーにしますか？1873年以前をエラーにしますか？（ヒント：明治六年）
テスト駆動開発、古い言い方で言えばテストファーストの考え方は、成功したすべてのプロダクトで例外なく、ただの一つの例外もなく、必ず最初から取り入れるべきだったものです。
品質は最後に振りかける粉砂糖のようなフレーバーではなく、最初から設計に組み込むべきだからです。
ありとあらゆる趣味において、最初から良いものを使えば時間を無駄にせずに済んだ、と言われるような初期投資の大切さが説かれます。
果たして本当でしょうか？
そうです、その趣味にハマって生き残りサバイブした人から見れば、過去にその時点で投資をすべきだった、というのは正しいのです。
その趣味にハマれなかった人からすれば、少ない投資で自分に合わないことが分かったという合理的な選択であることと矛盾しません。
そのため、全ての失敗したプロダクトは、テストケースを書く時間でプロダクトを作り上げて、さっさと世に問うべきだったわけです。
少し昔話をしますが、オフショア開発において重要なのはドキュメンテーションとテストケース、それにレビューでした。
他の部署で失敗しつづけていたオフショア開発のやり方は、端的に言えば"教化"でした。
具体的には書けませんが、グッとお安い単価の国に出す仕事を、日本の会社に出すのと同じようにすべく、相手の会社のメンバーを教育して仕立て上げるブートキャンプの仕組みを作り上げていました。
発注側を変えずに済むように受注側を教育して、日本の会社に出すのと同じように単価の安いところに出せたらお得ですよね？でもこれは必ず失敗します。
何故か。だって、日本の会社と同じように働けるようになったら、日本の会社に就職するじゃないですか。少なくとも価値は上がったんだから単価を上げるように交渉しますよね？
結局のところ、当初言われていたような劇的な節約にはつながらないわけです。それなら下手に転職されるよりも自前で現地工場でも立てて地元に貢献しつつ雇用を創出した方が喜ばれるし持続可能です。
小なりとも成果が上がった方法は、フィードバックを相手ではなくドキュメントにした場合でした。
例えば先ほどの例で言えば、テストケースは通るが意図したコードにならなかったとき。
「普通はこういう意図でコードを書くから、テストケースを通るにしても、関数は次からこう書いて」というのが、相手に対するフィードバック。
「関数を書く前に、関数の意図をコメントで残して、レビュー時にはそれを見ましょう」というプロセスの修正が、ドキュメントへのフィードバック。
こうすると、担当者が退職していなくなっても、次の担当者はその方法を参考にすれば良いわけです。
これ、何かに似てませんか。現在のAIコーディングのベストプラクティスと呼ばれるものに非常によく似ているんです。
つまり、オフショア開発というのも、設計と実装が分離できるという前提に立って動いていたんです。
そして、実装しながら設計しても問題ないとする場合、それは「技術的な問題」ではなく「組織構造」に起因します。
つまり、プロダクトの構造を分割して、オフショア開発側に設計と実装とを委譲して、実装しながら設計を変えてもらうことが許容できるのは、契約や責任分界点、輸出入の法規を含めた法務の領域です。
少なくとも当時、諸々をクリアにして相手側にプロダクトの一部を荒い設計と共に切り出して、コーディングしながら再設計してもらい、テストケースを完備したコードとドキュメントを共に完成までもっていってもらったことは、大きな成果であったはずです。
（当時日本側と仕事をしたという実績があると大きな実力があるとみなされたと聞いたので、今はより良いところで良い仕事をされていると思います）
（あと、コミュニケーションコストと輸出入の関連法規が複雑だから）
少なくとも、納期までに契約したこれを納品してください、という枠組みの中では、実装作業だけ切り出すことはできない、というのが教訓として残ったはずです。
少なくともあと数年、場合によっては10年スパンで、日本ではほとんど変わらないと予想しています。
これは技術の話ではなく組織構造や、もっと言えばお仕事の進め方と契約の話だからです。
そうは言ってもジュニアエンジニアの簡単な仕事が減って成長機会が失われているのは事実では？と思うかもしれませんが、そもそもの前提が誤っています。
未経験（弱経験）者を雇って戦力まで鍛え上げる必要があるなら、AIに仕事渡してないでそのジュニアエンジニアにやらせるべきなんです。
ジュニアエンジニアとAIと両方にOJTさせて、その違いをレビューの場でフィードバックしてジュニアを育てるわけです。
もし、そんな時間は無いというなら、元々ジュニアエンジニアをOJTで育てていたというのは幻想です。
（たまに、失敗が経験になるとして、会社に損害を与える方法でジュニアを"教育"しようとする人がいますが、商習慣的にも信義則違反ですし言語道断です）
シニアエンジニアだけで事足りるとしてジュニアエンジニアを雇わなかった企業は、シニアエンジニアが抜けてガタガタになります。
これは中核エンジニアがゴッソリやめた会社が傾くなんて言う話で、昔からそうです。（たいてい、もっと人雇ってくれ待遇上げてくれみたいな悲鳴を圧殺した結果だったりします）
昔から、中堅がやれば手早い仕事を新入社員にやらせて鍛える、その代わり質は悪いし時間もかかるしフォローも必要だったわけでしょう。
AI時代が到来するとしても全く同じです。AIが出力するコードレビューで悲鳴上げてる場合じゃないんですよ。
レビューできるシニアエンジニアが足りなくなると予想されるなら、当然、ジュニアエンジニア雇ってレビューできるようにする必要があるんです。
そしてそれは、技術的な問題点ではなく、組織的・経営的な決断です。
国産LLM開発の文脈でもそうなんですが、ハードウェアの進歩を無視して話をする方が多いのが気になります。
現時点のコンピューターパワーは、10年後には手の届く価格になる可能性が十分高く、もっと言えば20年後には個人が所有する可能性すらあります。
いまから20年前の2005年は、Youtubeが誕生した年です。その時に、誰もがいつも手元にビデオカメラを持ち、即座に動画を世界に公開できるようになるとは思っていなかった頃です。
今もそうだと思いますが、ある分野で必要な性能にはもう十分という期待値があり、10年経てばある程度大きな会社の部署単位で現在最先端のコーディングAIがローカルで動くようになると想像するのは容易です。
そうなったときに、果たして営利企業が、エンジニアを育成するというコストを支払うかといわれると、疑問です。その時点で今後のリアルなコストと比較対象可能になるので。
だって、筆耕担当者とか、清書担当者を雇わなくなった企業って、多いでしょう？
My job went toAI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
了解。元の論旨（「現実を直視せよ」）に乗っかって、「縮小均衡でいい」という主張への反論をまとめます。
インフラ（道路・上下水道・鉄道・送配電網・自治体運営・救急/消防）は固定費が大きい。人口・納税者が縮んでも費用は比例して下がらない。利用者減→運賃/料金↑→さらなる離脱→ネットワーク縮退…と負のスパイラルに陥りやすく、安定均衡より「崩れの連鎖」になりがち。
日本は食とエネルギーを外から買って生きる国。外貨を稼ぐ製造業・サービスの規模が一定ラインを割ると、交易条件の悪化、通貨の弱体化、調達コスト上昇が重なる。さらに国防は規模の経済が効く分野で、装備調達・人員維持・技術基盤に下限の規模がある。ここを割る「縮小」は安全保障リスクを跳ね上げる。
均等に縮むならまだしも、先に減るのは生産年齢人口。要介護・医療需要はむしろ増える。結果、依存率の上昇で一人当たりの負担が加速度的に重くなり、医療・介護・年金の給付削減か増税のどちらか（多くは両方）を強いられる。「ほどよい縮小」で止まらない。
学校・病院・路線・商業は一定の需要を割ると突然維持不能になる（段階的ではなく飛び石的に崩れる）。廃校・病院撤退・減便/廃線→通院・就学が困難→転出→税基盤縮小…と、局所的な“均衡”は成立しにくい。
研究開発、人材育成、スタートアップ、部材・設備・サプライヤーの集積は人と資本の密度が生命線。縮小は需要・人材プール・風呂敷（市場）を同時に縮め、投資採算を悪化させる。結果、技術導入・自動化で埋めたい穴がかえって埋まらない。
税収基盤↓／社会保障支出↑／インフラ更新費は下がらない。どこかで(1)給付削減、(2)増税、(3)政府債務増の選択になる。債務増に依存すれば、わずかな金利上振れで利払いが公共投資を食い荒らす。これも均衡を不安定化させる。
平時の“ギリ保てる縮小均衡”は、災害・資源価格高騰・隣国の圧力といったショックで簡単に壊れる。冗長性・予備費・防災力が痩せるほど、社会は脆くなる。
この骨太の“勘定”が示せない「縮小均衡」は、実質「均衡なき縮小＝衰退容認」に過ぎない。
「縮小均衡で十分」という言説は、固定費と最小実行規模、依存率上昇、ネットワークの臨界、地政学ショックを軽視している。多くの分野で均衡は連続的ではなく崖をもつ。ゆえに現実的ではない。
複雑なものをシンプルにする能力は、日本のWebサービス、特にインターフェイス設計（APIとUIの両方）において、しばしば課題として指摘される点だと思います。
ユーザー体験（UX）を損なう「使いにくさ」は、単なる実装力の問題ではなく、設計思想と要件定義の段階で、いかに「シンプルさ」を優先できるかにかかっています。
ご指摘の証券会社の例のように、ユーザーのニーズや行動よりも、企業の内部的な都合（例：部門間の連携、既存システムとの兼ね合い、法的な制約の過剰な解釈）が優先され、インターフェイスにそのまま反映されてしまうことがあります。
「銀行口座の同時開設」：これは、サービス提供側の都合で「ついでに登録させてしまおう」という発想、あるいは内部的なプロセスをユーザーに押し付けている典型例かもしれません。ユーザーにとっての最適な体験は、「必要な時に、必要なものだけを、わかりやすい手順で」提供されることです。
国産SNSの例で言われているWeb版実装の難しさは、まさにAPIインターフェイス設計の破綻を示唆している可能性が高いです。
これは、内部のシステムがモノリシック（巨大で密結合な一つの塊）になっており、データやロジックが明確なインターフェイス（API）を介して提供されていないことを意味します。
本来、アプリ版とWeb版は、同じバックエンドロジックとデータに共通のAPIを通じてアクセスするべきです。
それができないということは、アプリ版の実装がアドホック（場当たり的）で、APIではなく内部の構造に深く依存してしまっている証拠かもしれません。
「複雑なごちゃごちゃしたものを作れる能力」はあるという評価は、「機能の足し算」に長けている開発文化を指しているのかもしれません。
新しい要件やリクエストがあるたびに、既存のシステムに「機能を付け加える」ことには長けているが、「本質的でないものを削ぎ落とす」「複雑なものを抽象化して整理する」という「引き算」や「構造化」のスキルが欠けている。
「シンプルさ」とは、単に機能が少ないことではなく、「複雑な内部構造をユーザーから隠蔽し、必要な情報だけを整理して見せる」という高度な抽象化の成果です。
ご意見の通り、日本のWeb系で求められているのは、「複雑なものを実装する能力」のさらに上にある、「複雑なものをシンプルに設計し直す能力」、すなわち「本質を見抜く力」と「構造化・抽象化の思考」なのかもしれません。
環境：2006年式国産中古ガソリン直4ターボ270馬力＋ディスプレイオーディオ＋AppleCarPlay
試してみたのはYahoo!カーナビ、TOYOTAモビリンク。
先に結論。近所の慣れてる道を走るだけなら大同小異。どれ使ってもたいして変わらん。
まずUI。CarPlay 側の制約とかレギュレーションがあるのか何か知らんが、びっくりするほどUIやアイコンデザインが似ている。ドライブの途中で別のアプリに切り替えても、助手席に座ってる人は（注意深い人や詳しい系の人でなければ）気づかないだろう。なのでアプリの乗り換えはかんたんだと思う。
目的地検索はGoogle Maps が圧倒的に賢い。チェーン系のショッピングセンターをチェーン名だけで検索するとGoogle Maps は現在地から一番近い支店がちゃんとヒットしたが、ほかのはとんでもない遠距離にある支店しか出てこなかった。
曲がるタイミングの案内は、Yahoo!カーナビ、TOYOTAモビリンクはとても適正でゆとりを持って右左折の準備ができた。Google Maps は気持～ち遅い気がする（けど、使ってるうちに慣れて無意識に引き算するようになる）。
これ以上のことはもっと長距離で様々な条件下を走ってみないと何とも言えない。高速道路のちょっと複雑なジャンクションとかで差がつくかな。Google Maps はネズミ捕り情報や事故処理情報がけっこうリアルタイムで共有されてくるのでそういうところも実力の差が出る部分かもしれない。
ただ、自分はこのままGoogle Maps を使い続けると思う。Yahoo!カーナビ もTOYOTAモビリンク も、CarPlay の操作パネル上から「音声案内のON/OFF」を切り替えられないという私にとっては致命的な短所があったからだ。音量やON/OFFを切り替えるにはスマホ側を操作する必要がある（たぶん）。Google Maps はというと常時パネル上にスピーカーアイコンがあって、押せば音声案内は黙る。多くの人にとってはたいして重要な条件ではないかもしれないけどね。
私の声が聞こえますね……？
まず低温調理機とジップロックを買いなさい……低温調理機は鍋に挟んで使う物ならなんでも大丈夫です……
次に格安スーパーで鶏むね肉を2kg買うのです……冷凍の方が安いですがズボラには冷蔵のほうがオススメです……解凍が手間なのです……
業務スーパーの国産鶏むね肉冷蔵は2kg税込み1500円ほどで買えます……2kg1袋で７個ほど鶏むね肉が入っているのです……
・料理酒大匙１
・水大匙２
・塩小さじ1/2
・味の素５振り（だいたいでいい、おおすぎてもいい、多ければ多いほどうまい）
・胡椒５振り（てきとう）
を投入し、なるべく真空状態の密閉にして冷蔵庫で一晩置くのです……
翌日、鍋の中に水と低温調理機の入れて、低温調理機の設定を「６３度」「９０分」の設定し、設定温度に上がったアラームが鳴ったらジップロックを鍋に入れて完成を待つのです……
そうするとあなたの冷蔵庫にはクソウマサラダチキンが2kg入ります……。小腹がすいたらそれをかじるのです……。１日２個食べるなら4kg分作ってもいいでしょう……。いずれにせよ冷蔵一週間で食べきるのです……
国産って書いてるのより高かったのに😭😭😭😭🌰🐿️🍁
私が知っている著名人が逝去する機会はこれが初めてではないが、その中で最も淡々と受け止めた一報だった。
おそらく、生きていようが死んでいようが、まったく距離感が変わらない相手だからであろう。
私もかつて対戦FPSに関わっていたため、彼がFPS黎明期に身を投じた存在であり、大会での有名な壁抜きクリップを残していることも知っている。
しかし、私には、CSの壁抜き要素はあまりに一方的でローリスクハイリターンな行動に映り、正直いってくだらないとさえ思った。
「これを見てFPSを始めた人も～」というありきたりな賛辞は、私には疑問に思える。
あのクリップをもってしてFPS界の象徴として擦られても、ウメハラ氏の「背水の逆転劇」に比べれば、とても肩を並べるに値しないと思ってしまう。
これはnoppo氏がどうというより、対戦FPSというジャンルの限界である。
事実、FPSに携わっていた著名ゲーマーたちは、こぞってスト6に移行している。
国産ゲーであり、日本が世界でもトップクラスであり、盛り上がりも歴代トップクラスであり、なにより1対1での対戦で周囲の注目を一身に浴びることができるゲームに本腰を入れるのは当然だ。
マスゲームの駒の一人にすぎない、いわばモブキャラとしてキャリアを棒に振るだけの対戦FPSとは違う。
どれだけ著名なFPS元プロゲーマーであっても、そのファンミーティングで満足いく対戦もできない。
誰が壁抜きや待ち伏せや装備差でせこせこと勝ちを拾う卑怯者の我慢比べを楽しむだろうか。
したがって、FPS元プロゲーマーとファンとの交流は、おおよそ普段の対戦とは程遠い、運や緊張感だけが左右するミニゲームに甘んじるしかない。
FPS元プロゲーマーの肩書を背負ってのイベントコンテンツが、その専門性も技術にも触れられないじゃんけん大会も同然ではあまりに寂しい。
興行としてもタレントとしても、FPSというジャンルが抱えた限界を、著名ゲーマーたちは知ってか知らずか、いずれにしても今の状況に至るのである。
この訃報は一般のニュース経路ではなく、私に最適化された経路でしか知り得なかった。
これが仮にウメハラ氏の訃報であったなら、はてブでもyahooのリアルタイムトレンドワードでも知り得たであろう。
FPSをやっていた私ですら、自ら情報を取りにいかなければ知り得なかった。
あの「FPS界のレジェンドプレイヤー」noppo氏の名前を増田で検索しても、出てくるのは全国平均身長のWebサイトの話ばかりである。
要するに、そういうことである。
ご存じの通り、ペペロンチーノを作ろうとしても、オリーブオイル、国産大蒜はかなり高騰している。
安いサラダ油にしたり、大蒜を外国産（中国、スペイン他）にして問題無いなら、
外国産を使えば良いけど、味は落ちる。
それよりもコストを抑えるためには、レトルトのパスタソース、1人前ずつ小袋に入って、
2人前で100円台で売ってるやつを買うしかない。
正式名称は「アーリオ・オーリオ・ペペロンチーノ」（ニンニク、オイル、唐辛子）。
日本人が言っているのはこの省略形。
個人的には、ベーコンを入れた略称ベーコン入りペペロンチーノが好き。
オリーブオイルと、青森の大蒜、鷹の爪、塩、胡椒（個人的には白）を使うと旨いんだけど、
結構コストが掛かってる上に、ベーコンが追い打ちをかけてしまう。
節約したいのなら諦めてくれ。
その中でレモンが入っていた。
レモンマフィンをつくった。レモンの皮をすりおろしたのと、レモン汁をいれて、同じく入っていたしょうがのすりおろしを入れた。
おいしかった。
レモンはスーパーで売られている輸入の安いレモンだと、皮に農薬やワックスが残っていそうなのでつかいづらい。
スパイファミリーとか不滅のあなたへとか嘆きの亡霊とか続編モノは安定のクオリティで面白いけど(ワンパンマンは除く)
グノーシアとかチラムネみたいな明らかに切られそうな奴もエロがあれば何とか視聴継続出来るけど
なろう系は全滅だと思ってる。唯一作画水準が高めの最後にひとつだけも出オチ感半端なくて1話見たら満足しちゃったな。2話目以降は切り。
期待してたははのはもコミカライズの作画に到底及ばない劣化作画でガッカリだった
ワンダンスは内容こそ悪くなかったけど時折挟まれるダンスシーンは不気味の谷だしPAオリジナルのユウグレもアモルちゃんと子安がいなきゃ切ってるレベルでつまらなかった
前評判の高かった笑顔のたえない職場なんてアニメ見たら開始5分位でこれ何が面白いのかってなったよ
今期は国産アニメだけでなく中華・韓国産アニメも大量に放送配信されてて漫画版は面白く読んでたから期待したのにアニメはダメダメだった「ある日、お姫様になってしまった件について」も明らかに解釈違いと言わざるを得ない改変ぶりで萎えた。しかも初回SPって馬鹿じゃねえの？チラムネやグノーシアもだけど初っ端から長時間見せようとするな、きついんだよそういうの。
今期も前期以上にアニメが放送配信されてるはずなのに見たい作品が1話時点で殆どなくなったから久し振りに夜ふかしせず安眠出来そうだからそこだけは感謝してる。
2年前に下記にように書いたんだけど、懸念してた通りになりましたわね😒
2023-03-28
AIには学習データや調教が必要で、かつてのニコニコ・YouTubeみたいに法が整備される前に一般ユーザー集めた方が勝ちやぞ
ジャップランドはクリエイターや萌え豚をたくさん抱えているにも関わらず、PC音痴な人がぎゃおんして搾取されるだけなの、
マジなんとかした方がいいぞ
萌え絵は需要あるから、日本のクリエイターは海外AI勢にデータ学習で搾取され、萌え豚も萌え絵消費で海外AI勢に搾取される
真に日本がやらなきゃいけなかったのは、提携企業間ならクリエイターが自由にデータ学習を行えるようにする枠組みを作ることだったんやで
たぶん、ワイは100回くらい言った・・・・ってのはオーバーだけど、正直こうなることは、IT音痴以外のすべての人にとって知ってた速報だよね？
まぁ今からでも遅くない(？)から、ディズニーやマーベルみたいに、日本企業も圧力掛ける団体を作りつつの、
利害関係を丸めて企業間を超えてデータ学習をできる枠組みとクリエイター保護（学習に利用されたデータやそのデータを作ったクリエイターに報酬払う)は
やった方がええと思うよ
任天堂やセガやバンナムやサイゲなどの大手ゲーム会社や東映などの大手制作会社は上記でいい＋法務部と顧問弁護士に任せるとして、
「個別にオプトアウトしてね⭐️」って言ったって、どこからやるの？だし、
二次創作（ただし、二次創作ガイドラインがちゃんと公開されてるやつね)はどうするんだろ？ってなる
年がら年中、反AI勢とバトルしてる某氏が、まんま東方projectの二次創作アニメ、
というか、これまんま満福神社(https://youtube.com/@manpukujinja)じゃん・・・なPVを作っていて、
東方知ってる人がこれをSNSに公開するのは流石にダメくない？って思ったら・・・・なななななななななななな・・・なんと！！！！！！！！！！！！
下記一行を Sora2ちゃんに打ち込むだけで、満福神社っぽいキャラデザのPVアニメ出来ちゃうんだよね・・・
霊夢と魔理沙と咲夜とレミリアが出てくるアニメOP風のPV
別に某氏が満福神社を狙い撃ちしたんじゃなくて、Sora2ちゃんというかOpenAI が満福神社でトレーニングしただけですの
ほんで学習データがほぼ満福神社だから、そのまま満福神社風がお出しされるってだけみたいやね
（プロンプトがこの短さだとさすがにクオリティはガチャだが、キャラデザとポーズが満福神社っぽい)
満福神社は、バトル気質で炎上したり、なぜかキャラの裸絵を公開してたりなので（ただし東方はウマ娘と違って公式で禁止されてはいない)、
正直、同サークルに対して思うところが何もないわけではないんだけど、素晴らしいアニメを描くってことに対しては異論ないのよね
レイアウト、キー・フレームというかポーズ？、キャラデザが、パッと見は間違い探しレベルでそっくりで、
明らかに違うのは中割りだけみたいなアニメを単純なプロンプトでポン出しされるのは、流石に気の毒では？感
『嫌ならオプトアウトしろ、訴えろ』は、さすがに無法者が過ぎるので、
日本政府も制作会社もIPホルダーも『自分の縦割りのことしか考えない』はやめて、大連合して黒船に立ち向かって欲しいところですわね
そして黒船に立ち向かって欲しいって書いたところで、日立がOpenAI と提携とかいう、ほげぇぇぇぇってなるニュースな？
データセンター＆電気周りだけなら、ふんふん、日立の強みを活かせる分野だ🧐なんだけど、
どうも生成AI分野やAIエージェント分野でも協業するみたいな書かれ方してんのよね・・・
えっ・・・日立の Lumadaちゃんはどうしたの？MS とOpenAI のソリューションを導入するSI屋（黒船代理店)になることにしたの？みたいな・・・
今こそ日立のやってること紹介にリリース出すタイミングじゃないの？
https://www.hitachi.co.jp/New/cnews/month/2024/08/0828c.html
あと日立は公共事業部持ってて、公共インフラの構築も請け負ってるわけだけど、
えっ・・・日本政府も公共事業請け負ってる大大大企業も国産AIどうした？ってなる
『なんちゃってプライベートクラウド 〜謎の東京DC集中＆DR／BCP消滅を添えて〜』とかをかますくらいなら、素直にAWS やAzure 使えやとはなるし、
ゼロトラスト実現しよ？データ主権とかデータドリブンとかいう前にまずデータしっかり置こう？フルスクラッチで約束された失敗をかますくらいなら、
とりあえず、MSソリューションでいいよ（旧Google App／G Suite、現GoogleWorkspaceで通った道)ってなるけどさぁ、
インフラを請け負う大企業こそ、国と連携してデータ主権を守る姿勢を見せないと、国民のデータまで海外勢に握られることになりかねないやで
日本政府も大企業もスイスの国産AIくらいの頑張りは見せて欲しい
2024年7月、EPFL（スイス連邦工科大学ローザンヌ校）、ETHチューリッヒ（チューリッヒ工科大学）、スイス国立スーパーコンピューティングセンター（CSCS）は、大規模言語モデル（LLM）開発に関する共同プロジェクトを発表。
そして今、その成果が現実に：**スイス初の大規模・多言語・オープンなLLM「Apertus」**が公開された。
このモデルは、AIチャットボット、翻訳システム、教育ツールなど、あらゆるアプリケーションの基盤として開発者や組織に活用されることを想定している。
「Apertus（アペルトゥス)」とはラテン語で「開かれた」という意味。
この名前が示す通り、このモデルは以下すべてが完全公開・ドキュメント化済み：
ApertusはApache2.0ライセンスで提供されており：
• 商用利用もOK
•モデルサイズは**8B（80億）と70B（700億）**の2種類（小さい方は個人利用向き）
•ダウンロードはHugging Face経由、もしくはSwisscomプラットフォーム経由で利用可能
Swisscomや他のパートナー経由で、プロジェクトに組み込むこともできる。
「一部だけ公開」な他モデルと異なり、Apertusは“完全オープン”がモットー。
「信頼できる、主権を持った、包摂的なAI開発のリファレンスモデルを提供したい」
このプロジェクトは「研究→産業への技術移転」ではなく、イノベーションとAIスキル強化の起点として位置づけられている。
Thomas Schulthess（CSCS所長）はこう述べている：
「Apertusは新たなAIスキルと応用力を生み出す“触媒”になる」
Apertusは15兆トークン、1,000以上の言語で学習。
データの40％が非英語で構成され、スイスドイツ語やロマンシュ語など、他LLMで無視されがちな言語も多数含まれる。
「Apertusは“公益のためのAI”として設計された数少ないモデルの一つ」
— Imanol Schlag（ETHチューリッヒ上級研究員・プロジェクト技術責任者）
SwisscomはApertusを自社の「スイス主権AIプラットフォーム」でホスト。
Swiss {ai} Weeks では、開発者が実際にモデルを試し、フィードバックを提供する初の実験機会が設けられる。
「Apertusは公共の利益とスイスのデジタル主権のためのモデルです」
—Daniel Dobos（Swisscomリサーチ責任者）
スイス国外のユーザー向けには、PublicAI Inference Utility（PAIU）を通じてApertusが利用可能に。
「これは道路、水道、電気と同じく、“公共インフラとしてのAI”を示す証明だ」
Apertusはトレーニング全工程を再現可能な形で完全公開。
そして何より、以下の法的・倫理的ガイドラインを尊重して開発されている：
•著作権法
•パブリックデータのみ使用、機械判読可能な除外リクエストに対応
「Apertusは“パワフルかつオープンな生成AI”の実現可能性を証明した」
— Antoine Bosselut（EPFLNLP研究室長・SwissAI共同責任者）
これは完成形ではなく、始まり。
今後のバージョンでは：
https://actu.epfl.ch/news/apertus-un-modele-de-langage-multilingue-ouvert-et/#
