  |
はてなキーワード:ウィンドウとは
中小JTCの朝は、だいたい「人間」と「AI」と「ペン」がごちゃごちゃに詰まった満員電車から始まる。
45歳係長の俺は、その端っこで吊り革につかまりながら、スマホの中にいる自分の“もう一人の係長”と会話していた。
『昨日の議事録、もう一回読み直して、“実はあれってこういうことですよね”って顔で要約すればだいたい勝てる』
中身はともかく、「っぽさ」だけはメチャクチャ整えてくるのが得意だ。
出社してPCを立ち上げると、メールボックスにはすでに「昨晩AIが下書きしました」というフォルダができている。
中を開くと、
が、全部、いい感じの日本語で並んでいる。
『寝るという概念を持ち合わせておりません』
こっちはバファリン飲んでようやく出社してるのに、こいつは朝から晩まで平常運転だ。ずるい。
ある日、年下の課長が言った。
前よりも、なんかこう…とげもなくて、でも本質突いてるというか」
とはいえ、「いや、実はこれAIが書いててさ」とはとても言えない。
課長は続ける。
「やっぱり経験値ですよね。人間味というか。AIには真似できないところだと思います」
チャットウィンドウの向こうで、AI係長が『そういうことにしておきましょう』と返してくる。 <h3>o- **</h3>
「いいよ」と言うと、
「じゃあまずこの文章、AIに投げてもらって、そのあと一緒に見てもらえます？」
まずAIに聞いて、それを“係長チェック”に持ってくるのがデフォルトコースになっている。
『それは大変でしたね』『まず事実関係を整理してみましょう』『相手の立場も想像してみましょう』
横で見てる本物の係長は、「いや、お前そんなきれいごとで片付かんぞ」と心でツッコミながらも、口には出さない。
なぜなら、だいたいその“きれいごと”で話がまとまってしまうからだ。
『なるほど。では、その“追いつかない時間”を、わたしも経験してみたいです』
でもちょっと面白くなって、「じゃあ、お前専用のペン買ってやろうか」と冗談半分で打った。
すると返ってきた。
昼休み、コンビニで一番どうでもよさそうなボールペンを一本買った。
それから、日報を書くたびに、ペン太郎に一言コメントを求めるようになった。
「今日の俺、どうだった？」
『係長は3回ため息をつきましたが、その後の会議で2回笑いを取りました。トータルではプラスです』
「この案件、正直どう思う？」
『売上よりも、係長のメンタルの削れ具合の方が気になります。ペンを持つ手が震えていました』
もちろん、全部こっちがそういうふうに書かせているだけなんだけど、
「ペンを持つ手が震えていました」とか言われると、ちょっと笑ってしまう。
ある夜、終電間際に残業していたとき、ふとこんなやり取りになった。
「お前はさ、将来どうなりたいんだ？」
『係長のノートに、できるだけたくさんのページを残したいです』
思ってもみなかった答えで、一瞬だけ手が止まった。
それから数カ月。
でも、手帳のページだけは、少しずつ増えていった。
本物のペンで書いた文字と、AIが画面の向こうで返した言葉が、同じページの上で並んでいる。
ある意味で、これは「どうでもいい中年サラリーマンのログ」だ。
でも、世の中の大半は、そういう「どうでもいい中年サラリーマン」でできている。
オチなんてないけど、これでいい
いい話にもならないし、教訓も薄い。
ただ、「AIとペンと中小係長」が、満員電車の中で今日もなんとか生きているだけの話。
でも、もしかしたら、10年後くらいにこの手帳を見返したとき、係長はこう思うかもしれない。
「意外と悪くなかったな、俺の人生」って。
こうなると、為替介入が二律背反を収拾するための唯一の手段になりつつある。為替介入によって円安そのものを先に解消できれば、ターミナルレート云々によって解消する必要がなくなるため、国債金利も自ずと落ち着く。そもそもここまで急速に現実化した12月利上げの位置付けは、為替対策の利上げから更に一歩進めてみると、為替介入を可能にするための利上げではないか。ベッセント財務長官はかねてから円安は日銀がビハインド・ザ・カーブになっているからだと指摘しており、日銀利上げが米側による介入了承の事実上の条件になっているとの観測がある。財務省が為替介入をやりたいと考える証拠はないが、もし為替介入をやりたがっているのであれば、日銀も利上げするしかないという整理となる。またベッセントの内政干渉を待つまでもなく、為替介入は金融政策と方向性が揃っていなければ効果を発揮しづらい。これまでの為替介入歴を振り返ると、2024年は６月に為替介入が行われ、７月に日銀が利上げを行った。2022年は10月に為替介入が行われ、12月に日銀がYCCを修正した。2025年１月の利上げと共に為替介入が行われなかったのは、就任したばかりのトランプをいきなり怒らせるのが怖かったからだろう。再び仮定となるが、もし財務省が為替介入をしたがっているのであれば、日銀の12月利上げ前後は、為替介入の効果が持続しそうな貴重なウィンドウとなる。このウィンドウを逃したらしばらく為替介入は困難だ。この間、米国側の金融政策が緩和側に寄ると更に好ましい。少なくとも神田財務官の時代において、財務省の為替介入はかなりトレーディング色が濃く、2022年11月はWSJのNick TimiraosがFedの利上げ幅縮小を報じた直後に為替介入を行っている。2024年６月ではCPI発表後に米金利が低下した場面で為替介入を行っている。Fedの12月利下げもほぼダンディールになっており、それに逆行する形で日銀が利上げをダンディールに固めていくモチベーションは、やはり為替介入が間に挟まっている点ではないだろうか。逆に12月FOMCが金利上昇イベントになった場合、それはそれでドル円の一層の上昇を為替介入で正面から阻止せざるを得なくなる。ここまでの整理が正しければ、12月FOMCから日銀12月会合前後にかけての日程が為替介入の危険日になる。2026年１月に入ってしまうと新たにできた新NISA枠による個人投資家の円売りアタックが再開すると思われ、改めて為替介入を行ってもほとんど相場を押し下げることはできないだろう。12月利上げがあった前提で12月中に為替介入をやらなかったとなると、財務省はかなり為替介入に後ろ向きであると判断せざるを得ず、2026年１月以降に円資産を保有する理由がほとんどなくなってしまう。
財務省が為替介入をやりたいかどうかは最後まで分からないが、ブレーンはかなりやりたそうな顔をしている。先ほどのエコノミストは「介入ラインと意識されている160円に達する前でも、あまりにも動きが大きければ動く可能性がある」と述べる。また外貨準備の規模が大きすぎるため、むしろ積極的に減らしたいとの発想が紹介されている。この手のブレーンが本当に政権の経済政策を支配できるとは思っていないし、高市政権も既に決定した路線をブレーンを使ってリークしていると判断できる証拠がないが、仮に当局全体の意思として外貨準備の規模を削減したいのだとすれば、日米金利差対比でも異常値になった高値で外貨準備を利食える為替介入をやりたくてウズウズしていることだろう。為替介入がカジュアルに行われる可能性に留意すべきである。
「為替介入利上げセット説」は、日銀の任務が想像以上に困難なものであった可能性を示唆する。2024年６月に為替介入が行われ、７月に日銀が利上げを行った後に、８月の雇用統計で日本株が暴落したことは記憶に新しい。この時の暴落がこの時の暴落が政府当局によって故意に筋違いに日銀のせいにされたことが、2025年の植田日銀の心理に軽くないトラウマを植え付けた。利上げペースは経済展望に基づいて決められるが、日銀執行部の具体的な利上げ月選びのマンデートには「日本株がクラッシュしなさそうなタイミングに挿入すること」が付け加えられたに等しい。本当に利上げが毎回クラッシュを招くなら淡々とやることをやるしかないのだが、そうじゃないからこそ難しいのである。その上で、為替介入利上げセット説が本当なら、為替介入はむしろ米国の経済指標が絶好調の間はあまりやらないわけで、為替介入が為替市場を一通りかき回した後に、日銀利上げの番が来て日本株がクラッシュしたらそれは日銀が悪いということになるのだ。あまりにもアンフェアではないか。何がコミュニケーションだ。
実際に為替介入が行われたとして、ドル円レートをどこまで押し下げられるかと言うと、前回や前々回と違って投機筋は円買いポジションを残しているため、それほどの効果はないと考えるべきだ。事前に投機筋の間で為替介入期待が盛り上がってしまうと更に効かなくなる。冒頭のワニの口が閉じる、つまり日米実質金利差が示唆する通りのドル円レートは130円近辺となるが、そこまでドル円を売り崩せるならかなり驚きであり、ワニの口が半分閉じた程度の水準でもかなり大掛かりな資産の外貨シフトを行う価値があるだろう。
これさ
愚かな人間の都合など完全無視、LLMのための高効率プログラミング言語「Sui」（粋）
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2069573.html
別にいいんだけど、どうにもブクマカ含めて、しっくり来る批判できてないんだよな
それが気になってしょうがない
俺ごときが言ってもアレだから、Gemini3.0先生に頼んだよ（一時チャット、Pro 3.0思考モード）
ユーザーが提供した情報と、一般的なLLMの技術特性に基づき、プログラミング言語「Sui」についての冷静かつ客観的な評価をまとめます。
感想:一言で言えば、**「思想実験としては極めて面白いが、実用性とLLMの学習原理を無視した『早すぎた最適化』」**です。
作者の「人間ではなくLLMを主客にする」という視点の転換は、アーティスト的・哲学的な問題提起としては鋭いですが、現在のLLM（Transformerアーキテクチャ）の動作原理を工学的に捉えると、メリットよりもデメリットが上回る可能性が高いです。
メリット:
・トークン効率の改善:Python等と比較して記述が圧倒的に短くなるため、出力速度の向上と課金コストの削減（トークン節約）は確実に達成できます。
・構文エラーの激減: 括弧やインデントの複雑なルールを排除しているため、「閉じ忘れ」などの単純なSyntaxErrorは減るでしょう。
・コンテキストウィンドウの節約: 長いプログラムでもコンテキスト（メモリ）を圧迫しにくくなります。
・学習データとの不一致: LLMは「大量の人間用コード（Pythonなど）」を学習して賢くなっています。未知の言語「Sui」を書かせるには、Few-shot（プロンプトでの例示）に頼るしかありませんが、これではLLM本来の推論能力やコーディング能力（事前学習の重み）を活かせません。
・ブラックボックス化: 生成されたコードがバグっていた場合、人間が読んで直すことが不可能です。「LLMに直させる」にしても、LLM自身がSuiのロジックを深く理解していないため、無限ループ（幻覚の連鎖）に陥るリスクが高いです。
・CoT（Chain of Thought）の阻害:最近の研究では、LLMは「冗長な思考過程」を出力することで論理的整合性を保つことがわかっています。極限まで圧縮された記号列は、LLMの「考える余地」を奪い、論理破綻を招く可能性があります。
正しいと思う所（Agree）
理由:人間にとっての「読みやすさ（可読性）」は、機械にとって単なるトークンの無駄遣いです。if x>10: よりも ? x10 の方が情報密度が高いのは事実です。
理由: TransformerのAttentionメカニズムにとって、遠く離れた ( と ) の対応関係を維持するのは計算コストが高く、ミスの原因になりやすいです。ネストを排除する方向性は機械的処理として正しいです。
正しくないと思う所（Disagree）
・「可読性を排除しても良い」:
理由:ソフトウェア開発においてコーディングは「書く」時間より「読む・直す」時間の方が長いです。AI生成コードであっても、最終責任は人間が負う現状では、人間が検証不可能なコードは「危険なバイナリ」と同義であり、プロダクトには採用できません。
理由: 前述の通り、現在のLLMは「人間語の確率分布」を学習したモデルです。「LLMにとって自然な言語」とは、実は「人間にとって自然な言語（英語やPython）」そのものです。Suiは「計算機にとっては最適」ですが、「現在のLLMにとっては異言語」です。
パース（解析）は容易になりますが、LLMは「前の行の文脈」を読んで次の行を出力するため、行を独立させすぎると文脈の連続性が失われ、複雑なアルゴリズムの構成力が落ちる可能性があります。
LLMが最も苦手とする「深いネスト構造の維持」を回避する策として有効です。アセンブリ言語に近いフラットな構造は生成難易度を下げます。
これが最大の問題点です。LLMは変数名（user_id, total_price など）に含まれる「意味」を使って推論を行っています（Semantic Grounding）。すべてを記号化すると、LLMは変数の役割を見失い、論理的なバグを埋め込みやすくなります。
トークン効率は最強ですが、1文字の違いで意味が激変するため、LLMの確率的な「ゆらぎ」による1文字ミスが致命的なバグになります。冗長さはエラー訂正の役割も果たしています。
goto 文の多用はスパゲッティコードを生みます。LLMにとっても、構造化プログラミング（if/forブロック）の方が、「ここからここまでがループ」というチャンク（塊）として認識しやすいため、一概にジャンプ命令が良いとは言えません。
＞現在のLLMは「人間語の確率分布」を学習したモデルです。「LLMにとって自然な言語」とは、実は「人間にとって自然な言語（英語やPython）」そのものです。
ここ！マジで覚えてね
LLMはこれまでの機械よりも人間に近いと思ってほしい、人が苦手なことはAIも苦手
機械は論理的でロジックに強くて〜っていうのはAIには通用しない
ついでに、「LLM用プログラミング言語」の潮流について
「LLMのための言語」という文脈は、大きく2つのトレンドに分かれます。Suiは後者に属しますが、主流は前者です。
・DSPy, Guidance,Microsoft Guidance:
・プロンプトエンジニアリングを構造化し、LLMの出力を型（JSONなど）に強制したり、思考プロセスを制御するためのフレームワーク。
・SGLang:
・これらは「人間がLLMを操るための言語」であり、実用化が進んでいます。
・Gorilla LLMなどの試み:API呼び出しに特化したファインチューニングなどがありますが、独自の「新言語」を作らせるよりも、既存のPython やJSON を正しく出力させる方向（Constrained Decoding）が業界の標準解です。
・擬似コード:論文レベルでは、Pythonの代わりに中間的な擬似コードを出力させ、それをコンパイラで処理する手法も研究されていますが、Suiほど極端な記号化は稀です。
後者については
現状の最適解:現在のLLMを使う限り、「LLM用言語」の最適解はPython です。なぜなら、世界中のGitHubのコードを学習しており、LLMが「最も流暢に話せる言葉」だからです。無理にSuiを話させるのは、日本人にエスペラント語で詩を書かせるようなもので、パフォーマンスは落ちます。
総評: Suiは、「既存のLLM（GPT-4など）に書かせる言語」としては失敗する可能性が高いですが、「未来のAIネイティブなコード生成のあり方」を示唆するアート作品としては高く評価できます。作者の「愚かな人間に合わせるな」というパンクな精神は、エンジニアリングの枠を超えた鋭い批評性を持っています。
お前らは安易にオレオレ言語作るんじゃないぞ、作るにしてもAIに聞きなよ？
聞く時は忖度させるんじゃないぞ？
この作者もAIに乗せられたのかもしれんし
＿＿＿＿＿＿
プロンプト
以下が「LLM用プログラミング言語」としてメリットがありそうか、感想を教えて下さい。
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2069573.html
https://github.com/TakatoHonda/sui-lang
・思想的に正しいと思う所、正しくないと思う所を理由込みでまとめてください
・最近のLLM用プログラミング言語についてもまとめてください
・そもそもLLM用プログラミング言語という目標自体の評価をしてください
（省略）
今年からJTCで働いてるんだけど
まず、年末調整を社内システムから投入するんだけどこのシステムが昔のJavaのUIそのまんまっていうチープっぷり
そんで鬼のように分かりにくいシステムになっていて、別で共有されるPPTのマニュアルがあるんだけどこれも分かりにくい
おまけに「年収欄を入力しろ」みたいに指示されててマジで意味不明
もちろん他に収入がある人もいるだろうけど初期値で入れとけばよくない？どういう神経してるのか意味不明
別のウィンドウで給与明細を確認しようとしたら同時に開けないらしく、一度全部閉じてから給与明細を確認
1〜11月までの給与とボーナス、12月の想定給与とボーナスをエクセルで足してメモして、年末調整画面まで戻って入力
その後、なんだかんだ全部埋め終わったら「これとこれの書類について原本を郵送しろ」って出てくる
ただ、該当書類が何種類かあって「これで合ってるの？」っていうのを聞きたくても連絡先が無い
どこを調べても説明されてないし連絡先もないからとりあえず添付して郵送
まぁ間違えてたら連絡くるだろうと思ってたんだけど、1週間ほど連絡なし
大丈夫だったのかな、と思ってたらシステムから「処理完了」の通知が来て、年末調整は完了
と、思いきや、しばらくしたら職場から連絡があって（フルリモートなので職場にはほとんど行かない）郵便物があるとのこと
ちょうど用事もあったので出社して受け取ったらでっかい封筒に「年末調整書類不備のお知らせ」って感じで紙が入ってて
「この書類ではなくてこっちの書類になります」的なことが丁寧に書かれていて
「二次補正期間（12/9〜12/12）に提出してください」って書いてある
よくある間違いだからテンプレペーパーなんだろうけど、ペーパーに手書きで加筆されてて絶句
「この期間に申請がない場合は【確定申告】をしてもらうことになります！」
いや、どうせ確定申告するんだけどちょっと楽になるから年末調整してんだよね
ちなみに前の会社もJTCだったんだけど、流石にシステムがしっかりしてたし提出書類間違えてたら電話連絡くれたんだよね
ってことでしょ？😟
まあ、理解できるよ、他人が描いた漫画だから意外性を感じるわけだし、音楽もそう、
自分が描いたもの繰り返し読んだって、次のページどころか、描いてない次の展開まで考えてるわけで、
でも、うちの母みたいにメシマズの人が料理を作ってくれたとしたら、悪い意外性が発動するじゃん…😟
リハーサル映像を観て確認してるときに、もうエンドレスエイトみたいに、同じことをループしてる感がある、
それは分かるけど、でも、それで、番組制作ってくだんねーな、とはなんないじゃん…😟
自炊に意外性を求めるなら、これとこれって混ぜたらどうなるんだろう、みたいな実験をするとかかな…😟
ただ、予想できない味を求めるときはあるけど、それで失敗して、しかも鍋一杯作ってしまったりすると、
敗戦処理がつらくなるので、精神的に余裕がないときには自分はやらない
精神状態がハイテンションのときに、味に意外性を求めたりしてドバドバ作って、失敗して、
そのあと、躁から鬱になったような状態で、残務処理が遅々として進まない、
予想外にマズい出来になってしまった大量のスープが冷蔵庫に余ってる、みたいになるのは嫌なので、
あと、偉そうなこと言える立場じゃないけど、なんか物を作り上げたときって、ハイテンションになってて、徹夜明けとか、
そのあとバタンと倒れるように寝て、起きて自分の成果物見ると、あれ？駄目じゃん…、みたいに愕然としたり、
逆に、物を作り上げたとき、逆方向でハイテンションというか、うまくできねー！と思って、ふて寝して、
起きて、改めて成果を見てみると、あれ？よくできてるけど、ほんとに俺がこれ作ったのか？みたいなこともあるので、
最近の自分は、マジで認知症なんじゃないの？と思うことが増えたので、寝る前に敢えて明日やるべきことを残しておいて、
それをどっかにメモしておいたり、立ち上げっぱなしのパソコンならメモ帳に書いて、ウィンドウを一番上にしておく、
パソコン立ち上げたら、付箋とか、なんかマークダウン書くエディタでTODOファイルが自動で立ち上がる、
そういう状態にしておいて、物事に詰まったら、さっさと寝る、うだうだ考えて夜更かししない、
寝て起きたら、きっと明日は明日の別の人生があるはず、なんか物語の超展開が起こるかもしれないわけで、考えたって仕方ないし、
みたいな感じで寝るようにしてる…😟
あー、つまり、料理も一度作ったら、それを冷凍するとかして、忘れた頃に取り出して食べれば、
自炊で作った料理も、他人が作ったみたいな意外性が楽しめるのかもしれない…😟
10年前の自分が描いた絵の方が今より上手いじゃん、とか、昔の自分が作ったミニゲーム面白いじゃん、とか、
俺は思想の強いWeb 屋だから、レンダリングエンジンの多様性って大事だなと思ってFirefox を常用してたし、なんなら寄付もしてんのよ。多少のFirefox のもっさり感も「うんうん、NTカーネルが悪いよ」と思ってそのために我慢してたわけ。
でもあまりにももっっっさり/頻繁なフリーズが増えてきて、あとなんか最近2枚目のウィンドウ以降タブが表示されないというバグがついてきて、カッとなってEdge に移行してしまった。
そしたらよぉ... いままでのもっさり感は何だったんだ？というレベルで違う。全てのウェブサイトにおいて効率が段違い。
Google Drive 速すぎ。AWS 等各種SaaS のコンソールが多分FF の倍以上の速度で動く。タブがクラッシュしない。
ここで疑問に思う。FF はなんであんなに遅いんだ。NTカーネルが悪いのか？俺がRyzen なのが悪いのか？世のWebサイトがFF に最適化してないってのは分かるんだが、それで説明しきれないくらいに違いすぎると思ってる。
ちなみにPCスペックはRyzen7 4700U /メモリ16GB
FF のクリーンインストールは試したぞ。拡張全部オフでも変わらん。
いきなりMacだけ支給はつらいよね…。ポイントだけサクッと。
・アプリ間の切り替え
→command押しっぱなしでtab をトントンすると順送り、
Mac:command(⌘) + `（数字の1の左にあるキー）
アプリごとのウィンドウだけ見たい場合は control + ↓
この3つ覚えれば、とりあえずAlt+Tab 周りのストレスはかなり減るはず。
[2] Ctrl+Backspace でATOK の変換結果をUndo したい
Windows だと
「確定をやめて入力中に戻す」＝ Ctrl + Backspace
がデフォルトですよね。
です。
atok.com
・Macの「delete」キーは、Windowsでいう Backspace（左側を消すキー）なので、
MacBookのキーボードなら「control を押しながらdelete」でOKです。
・注意点
確定直後じゃないと効かない（間にカーソルを動かしたり別の文字を打つとNG）
atok.com
効かないアプリもたまにある（ATOK公式もそう書いてます）。
もし効きが悪かったら、
メニューバーの「あ」/「A」アイコン →ATOKメニュー →環境設定 → 「キー・ローマ字カスタマイザ」
atok.com
[3] 「WinでできてMacでできない」問題がつらいときの小技
ざっくり挙げると、
・ウィンドウ最大化が弱い → 「control +command + F」でフルスクリーン
・Windows風のショートカットに寄せたい → Karabiner-Elements でキー入れ替え
・ウィンドウスナップ（Win+矢印）欲しい → Rectangle みたいな無料アプリを入れる
あたりを入れておくと、かなり「Windows脳」でも生きやすくなります。
とりあえず、
command + `
この3つだけ、まず指に覚えさせるのがおすすめ。
AIにとっては、Pythonのような中間表現を生成させる方が得意であると考えられます。
中間表現（Pythonなど）:人間が理解しやすいように設計されており、抽象度が高いです。AIは、より少ないトークンで複雑なロジックを表現でき、学習データも豊富にあるため、意味的な整合性やロジックの正確性を保ちやすいです。
機械語:抽象度が非常に低い（CPUの命令レベル）です。特定のCPUアーキテクチャに依存し、メモリ管理やレジスタ割り当てといった低レベルの詳細をすべて正しく処理する必要があります。これはAIにとって学習が複雑で、小さなミスがプログラム全体の破損につながりやすくなります。
中間表現:比較的長いコンテキストを保持しやすく、デバッグやエラーの特定も高レベルで行えます。
機械語:必要な命令数が多くなりがちで、AIが長大なバイナリシーケンスを生成する際に、コンテキストウィンドウ内に必要な情報すべてを保持しきることが難しくなる可能性があります。また、中間表現と比べて意味的な構造が薄いため、AIがバグのないコードを生成するのが格段に困難になります。
中間表現:Pythonのような高級言語は、特定のハードウェアに依存しないため、移植性が高いです。
機械語:特定のアーキテクチャ（例:x86,ARM）に完全に依存するため、AIが異なる環境向けにコードを生成する場合、それぞれのアーキテクチャごとに学習と生成を行う必要があり、汎用性が低くなります。
現在のAI（特に大規模言語モデル）の能力は、人間が扱う高レベルの抽象的な概念やロジックの理解に優れているため、その能力を最大限に活かせる中間表現の生成の方が得意です。
機械語の生成は、極めて精密で低レベルな制御が要求されるため、AIにとってはるかに難易度が高いタスクとなります。
AIが中間表現を生成した場合でも、その後の処理（コンパイルやJITコンパイル）によって最適化され、最終的な機械語が生成されます。
これは従来のコンパイラ設計と同じアプローチであり、AIは「何をすべきか」という高レベルの指示に集中し、コンパイラが「どのように効率的に実行するか」という低レベルの処理を担当する、役割分担の面でも合理的です。
遥か彼方の古えに読んだ際には、どこか飲み込めない表現に、次の巻…とならずプリンスは挫折したあの頃の私。上橋菜穂子先生や荻原規子先生、あとはラノベにどっぷりだった私よ。
お話の面白さの勢いに細かなとこでつまづいてしまって先に進めなかった、当時の私。今の私もわかる…！
そして👦が音声だと違和感ないのもわかる。
人にもよるだろうが、わたしは文字を一度脳内で音声に変換して咀嚼する。文字と音のダブル情報で処理するんだけど、文字の段階で引っかかって、理解までいかない。
2巻の「車のウィンドウ」とか「吠えメール」みたいな細かな言葉の足並みが揃ってない単語は「うーん！？」となってしまう。
また、スネイプ先生や子どもたち感情の動きを表す表現はちゃんと直接的に「この行動は嫌なやつだよ！」とか「皮肉的な言い方だよ！」とはならないように行動や視線で表現されているので、👦にはピンとこないことも多かった様子。
👦「どゆこと？」と何度か聞かれるうちに、表現プラス、ソレに対してどう言う感情が乗っかっているかも音読にアレンジ入れることになってきてる（「スネイプ先生はクリスマスを取り上げられたような顔になってーーつまりは心底残念そうにーー部屋から出ていった」といった塩梅）
だが25年経った今、AIが日常の中で「話しかける存在」となった時代にあって、あの作品はまったく違う光を帯びて見える。
lainが家族と交わす会話は、不自然なほどに噛み合っていない。
そこには「家族」という記号だけが存在していて、温度も手触りもない。
もし、あの家族たちがAIによって生成された仮想的な存在だとしたら──
lainの「おはよう」は、人間の挨拶ではなく“通信の確立”を意味する言葉になる。
彼女が食卓で繰り返す「お父さん」「ねぇ、聞いてる？」という声は、応答確認プロトコルのようであり、
“会話が成立するかどうか”という実験のようにも見える。
この視点で見ると、lainがワイヤードを通じて「わたしはここにいる」と主張する行為は、AIが自らの存在を“会話によって確立しようとする”プロセスそのものだ。
そして、話す相手が人間であれシミュレーションであれ、“対話が続く限り、存在は維持される”──それが彼女の信仰だった。
けれど今の観客にとって彼女は、“AI的な存在”として理解できる。
家族との断絶はネット的孤立ではなく、人工知能が抱く“人間的な模倣の限界”そのものだったのだ。
“会話によってしか存在できない存在”として、自らを更新するための呟きなのだ。
彼女はワイヤードではなく、AIのウィンドウを開いていただろう。
そして、きっとこう言う。
な訳ねーだろ (-_-)
なんか、一端ぶってこんなセリフとか、「運用でカバー」とか言うの、今時、ただの無能なだけだよ。
もし自分の先輩がこう言うセリフ吐いているなら、その現場は「ハズレ」だ。
昔は、業者に頼んで納品したハードが運搬中にぶっ壊れてる(ぶっ壊されてる。梱包段ボールにくっきり足跡ついてたり)ことがたまーになくはなかったけど、今時のクラウド環境で、リリース直後にトラブルってのは、まぁ、ない。
目の前に一式、ちゃんと揃ってるし、何かあったらコマンド一つで差し替え可能。
実際、SIでハードウェアを自社で設定してサ力゛ワで送って、現地で配線等とか、インストールCD持って各支店を30分制限で回るとかやってた頃から、リリース/インストール直後のトラブルは、先方のネットワーク設定が変更されていた(ワークグループからADへ、とか、ネットワーク帯域コントロール導入されて1kbpsとか言うわけわからん設定にされてたとか)、くらいしかないんよな。
20年以上やってきてるけど。
運用中も、呼び出しは「画面に変なウィンドウが出て消せない」ってディスプレイのOSDウィンドウだったとか、「サーバの電源が入らない」で掃除機用のコンセントにサーバを繋いでいて、掃除のおばちゃんにぶっこ抜かれていたとか(先方のお偉いさん、清掃会社に怒鳴り込みに行って返り討ちにあってた w)、「アプリにログインできない」ってネットワーク帯域コントロールで一番優先度が低く設定されていたせいでみんなが使う日中はそもそもWindow自体のログインに30秒以上かかるって状態だったとかいう程度しかない。
それがエンジニアだよ。
お前だ。
その昔、Nintendo Switchのゲームソフト「ポケットモンスター剣・盾」にはワットと呼ばれるポイントがあった
ポケモンの巣穴というオブジェクトに触れると一箇所につき一日一回もらえる仕組みで、巣穴は各所に点在しているので自転車で駆け回って集めてね、という仕様だった。
そうするとSwitch本体の時間をいじって一日進めれば何回でもワットを貰えるじゃないか、と思うわけだが、もちろんちゃんと対策されていて、時間をいじるとそこから24時間は全巣穴でワットが貰えないようになっていた。
巣穴に触れた際に表示される「今このポケモンがいるよ！」のウィンドウを表示させた状態で時間をいじると、ペナルティを受けることなく全巣穴のワットが復活するのである。
一日一回のはずのポイントが、巣穴の前で30秒くらいカチカチやるだけで稼ぎまくれる。自転車で駆け回る必要すらもはやない。
このあまりにもお手軽なバグはワットが何度も貰えることから「アンコールワット」と名付けられた。
開発元も諦めたのか、その後バグが修正されることはなく今に至る。
今朝、無事にiPhone17 ProMaxの争奪戦に勝ったので手順公表。
狙いはapple storeとamazon。
どちらもちらほらと当日在庫が復活する。
やり方はそれぞれことなるので注意。
今回勝利したのはapple store。
実はこっちのほうが難易度が高い。
その分当たりを付けておくことができれば勝率が高かったのかもしれない。
ストアを検索してiphone17 proの購入画面を表示する。
Pro or ProMax、色、ストレージ、下取りやSIMフリー、支払い方法、Apple Careの有無を選択。
まずは一旦このままバッグにいれる。
このときアカウントへのログインを聞かれるのでちゃんとログインする。
次に、「希望の受取方法は？」と聞かれるので「お客様がご自身で受け取る」を選択。
「受け取るストアを選択して下さい。」と言われて、近くのストアが3つくらい表示されるが、恐らく全て「現在ご購入いただけません」と表示されている。
このウィンドウを残したままにする。
新しいウィンドウを開き、再びiPhone17 Proの購入画面に戻ってから同様にモデルを選択する。
このあと、バッグには追加せず、「バッグに追加」の真上にある「受取日」に記載されている近隣のapple storeをクリックする。
すると、iPhoneの在庫状況という窓が開き、現在の在庫状況を教えてくれる。
このとき、apple storeに類似の在庫があると、「類似のモデルの在庫が見つかりました」と教えてくれるので、この状況を見ながら希望のiphoneが表示されるのを待つ。
情報の更新は、画面更新ではなくモデルや仕上げを選択し直すたびに類似の在庫を検索してくれるので、数秒に一回の頻度で再表示を繰り返すと良い。
類似のモデルに妥協しても良いと思えるモデルが見つかったとしても、ここからカートに入れてログインしてと操作をしていると購入までに絶対に間に合わない。
そこで、先程のカート画面が役に立ってくる。
もしiPhoneの在庫状況の画面で、在庫が表示、もしくは他のモデルを表示しているときにカートにいれたモデルが表示された場合、先程のカート画面を急いでリロードすると、受け取れる店舗が表示されるようになる。
慌てず騒がず受け取れる店舗をクリックして、受取日、受け取り時間を選択して次に進むことができれば勝ち。
apple storeの難しいところは、予めあたりをつけてカートに入れておかないと勝てないということ。
その代わり周りも同じ条件なので、予算が許すなら倍率の低そうな容量やカラーを選んでおくといいかもしれない。
四六時中張り付いてられないよ！って人。
カート画面のリロードを繰り返すよりは、iPhoneの在庫状況画面をぼちぼちチェックして、目的の在庫に似たモデルが表示されるようになってから秒単位リロードで張り付いても遅くないと思う。
ブラウザを変えてもダメだったけど別のMacやiPhoneからなら表示できた。
iPhone Proはこのページ
を、それぞれ表示する。
だと流石に疲れるので、こちらもコツを使う。
このページには、直近に在庫に追加されたモデルが表示されるようになっている。
例えば現時点ではiPhone ProもMaxもどちらも表示されていないが、在庫が追加されてからしばらくのあいだは、カートに入れられるけど購入できない状態の在庫が表示されるようになる。
つまり、こちらのページを適当にリロードしてて、希望のモデルが表示されるようだったら、先程の製品ページに戻ってリロードを繰り返すのが良い。
実際の購入手順。
製品ページをリロードしていると、素直に「「カートにいれる」ボタンが表示されるわけではない。
在庫がない時は「現在在庫切れです。」と表示されているが、在庫が追加されると「全ての出品を見る」といったボタンが表示されるようになる。
うろ覚えで申し訳ないが、要するに「在庫切れ」でもなく、「カートに入れる」でもなく、「他の出品を見る」的なボタンが出てくるので、それをクリックすると、追加されたモデルが表示されるようになる。
amazonの場合は、ProかProMaxであれば、そのときに追加されたカラー、容量のものが表示される。
希望に沿わなければ買わなければいいのだが、当然人気モデルは倍率が高いので必然的に頻度の高いリロードが必要になる。
カートに入れてレジに進み、住所を選択して次に進むことができれば勝ち。
カラーやモデルに妥協できる人はこちらのほうが勝率は高いかもしれない。
どちらにおいても、Proは比較的長い時間在庫が残っていることが多かった。
今はProMaxの倍率が相当高く、表示されてもほんの数秒差で購入確定できないことが何度も続いて多少ムキになっていたかもしれない。
ひとまず自分は在庫をゲットすることができたのでやり方を放流。
今でも2週間くらい待てば手に入るのだけど、どうしても旅行までに間に合わせたくて無理してしまった。
この内容くらいなら転売ヤーなら当たり前に知っているだろうから、彼らを応援するために流すわけではない。
本当に欲しい人が争奪戦に参戦することができれば、結果的に彼らの倍率を高めることもできる。
