今週もプログラミング雑記からGo言語の話題を中心に気になった話題を取り上げていきます。
前回からだいぶ間が空いてしまいすみません。
Go言語
Go言語
Go 1.26は言語仕様の拡張、ツールチェーン強化、ランタイム最適化、標準ライブラリ拡充が中心のリリースです。
言語面では、new が式を受け取れるようになり、オプショナル値のポインタ生成が簡潔になったほか、ジェネリクス制約で自己参照が可能になりました。ツールでは go fix が全面刷新され、モダナイザ群とインライン機能により既存コードを最新のイディオムやAPIへ自動変換できるようになっています。ランタイムでは Green Tea GC がデフォルト化され、GCオーバーヘッドが実運用で約10〜40%削減されることが期待され、cgo呼び出しのオーバーヘッド削減やヒープベースアドレスのランダム化も行われました。また、ゴルーチンリーク検出用の実験的プロファイル goroutineleak が追加されています。 標準ライブラリでは HPKE を実装する crypto/hpke、アーキ依存SIMDを扱う実験的 simd/archsimd、秘密情報用の runtime/secret など多くの新API・改善が追加され、各種ポートやWebAssemblyのメモリ使用効率も向上しています。
感想:
遂にリリース。GCの更新が一番大きいと思いますが、go fixの強化も既存コードのモダナイズに役立ちそうです。
Go 1.26の新機能を紹介するJetBrains主催のライブ配信イベントで、日時は2026年2月19日16:00〜17:30 UTCです。
Anton ZhiyanovがGo 1.26の重要な更新をライブコーディングで解説し、その後Alex RiosがGoLandによるGo 1.26対応と開発支援機能を紹介します。
Microsoft製Go 1.26.0-1が公開され、標準Go 1.26相当をベースにMicrosoft独自のバージョン情報埋め込みやビルドキャッシュ分離が行われています。
systemcrypto周りでは、環境変数での無効化方法の整理、WindowsのFIPS設定時パニック解消、Linux向けのcgo不要なOpenSSLバックエンドやFedora FIPS対応強化、macOSバックエンドの正式サポートなどが含まれます。
TLS設定も社内ポリシー準拠となり、AES-256優先やCHACHA20_POLY1305の優先度調整、特定カーブやプロファイルをGODEBUGで制御可能になっています。
この記事では、GoLandがGo 1.26対応として提供する構文アップデート支援機能を紹介しています。
Go 1.26では型安全なエラー展開を行うerrors.AsTypeと、式を直接渡せるnew()によるポインタ生成が追加され、GoLandはこれらのパターンを検出してクイックフィックスで自動変換します。
エディタ上では「Syntax updates」という専用の弱い警告として青い下線で表示され、振る舞いを変えずに安全にモダナイズできる箇所のみを対象とします。
一箇所に適用した後は、「Analyze code for other syntax updates」やRefactorメニュー、go.modからの操作などでプロジェクト全体に一括適用でき、Problemsツールウィンドウで差分を確認しながら個別または一括で適用できます。
これにより、大規模な移行プロジェクトを立てずとも、日々の変更の中で少しずつコードベースをGo 1.26スタイルへ近代化できるようにすることが狙いです。
この記事は、Go 1.26で実務に直結して役立つ3つの新機能を解説しています。
1つ目はerrors.AsTypeによる型安全かつ高速なエラーハンドリング、2つ目はnew(expr)で値付きポインタを簡潔に生成する機能、3つ目はanalysisベースに刷新されたgo fixでコードを自動モダナイズできる点です。
Go 1.26では、go fixサブコマンドが完全に刷新されました。
主な機能
go fix ./... を実行するだけで、コード全体を自動的にモダナイズできます。-diffフラグでプレビュー確認も可能です。組み込みのアナライザーには、interface{}をanyに置換、min/max関数の活用、strings.Cutへの書き換えなど多数が含まれています。
背景と動機
Go 1.18以降、ジェネリクスや新API（strings.Cut、maps.Keysなど）が多数追加されました。しかしLLMコーディングツールは古いスタイルのコードを生成しがちで、新しいイディオムを反映させるためにも、オープンソースのGoコードをモダナイズする必要がありました。
技術基盤
Go 1.26でgo fixはGoアナライザーフレームワーク（従来はgo vetが採用）に統合され、実装が統一されました。複数の修正が同一ファイルに適用される際は三方向マージアルゴリズムで競合を処理します。
「セルフサービス」へ
今後はサードパーティAPIのメンテナーが独自のモダナイザーを定義・配布できる「セルフサービス」パラダイムへの移行を計画しています。Go 1.26ではその第一弾としてアノテーション駆動のインライナーが導入されました。
この記事は、GoにおけるDI（依存性の注入）の基本と、DIコンテナであるuber-go/digの使い方を解説し、newの連鎖で肥大化しがちなmain関数から依存オブジェクト生成の責務を排除して設計をシンプルかつテストしやすくする方法を紹介しています。
この記事では、Goのlen()は文字数ではなくUTF-8のバイト数を返すため、日本語や絵文字を含む文字列の「文字数」取得には不適切だと説明しています。
日本語などマルチバイト文字の数を数えるにはunicode/utf8パッケージのutf8.RuneCountInString()を使うべきですが、複合絵文字は複数のruneで構成されるため、見た目1文字でも複数カウントされてしまう問題があります。これを解決する手段として、字素クラスタ（grapheme cluster）単位でカウントできるOSSライブラリgithub.com/rivo/unisegを利用し、uniseg.GraphemeClusterCount()で見た目通りの文字数を取得し、uniseg.NewGraphemes()で見た目1文字ずつ処理する方法が紹介されています。 最後に、用途に応じて「バイト数＝len()」「rune数＝utf8.RuneCountInString()」「見た目の文字数＝uniseg.GraphemeClusterCount()」を使い分ける重要性がまとめられています。
この記事は、Cloud Run 上の gRPC 通信で頻発する Unavailable エラーに対し、アプリ側での Keepalive・MaxConnectionAge・リトライ実装など「泥臭いチューニング」で対処したが、それは車輪の再発明だったと振り返っています。 現在は、gRPC 互換で HTTP/1.1 にも対応しクライアントコードを簡潔にできる Connect と、リトライや接続管理・ヘルスチェックなどレジリエンス機能を担う Envoy をサイドカーとして採用する構成を推奨し、ネットワークの不安定さはインフラ（プロキシ）に任せてアプリはビジネスロジックに集中すべきだと結論付けています。
goのツールを一括アップデートできるgupが1.0.0になっていた。おめでたい。🎉🎉🎉
使い方はこちら。
Mozillaは、OpenAIやClaudeなど複数のLLMプロバイダーを統一インターフェースで利用できるGoライブラリ「any-llm-go」を公開しました。
このライブラリは、Python版「any-llm」のGo移植版で、8つのプロバイダー（Anthropic、DeepSeek、Gemini、Groq、Llamafile、Mistral、Ollama、OpenAI）に対応しています。プロバイダーごとの異なるAPI仕様をまとめることで、コード書き換えなしでプロバイダーを切り替えられます。
any-llm-goはGoの特性に合わせた設計で、ストリーミングはチャネル、エラーハンドリングは型付き値を使用しています。OpenAI互換APIに対応したプロバイダーは数行の実装で追加可能です。
今後はCohere、Together AI、AWS Bedrockなど新たなプロバイダーの追加やバッチ処理対応を予定しており、開発者の貢献を歓迎しています。
感想:
GoでLLMを使うためのベターなライブラリがなかったのですが、これで標準が出来た感じがありますね。
JetBrainsは、AIエージェント（JunieおよびClaude Code）がモダンなGoコードを生成できるよう、新しいプラグイン「go-modern-guidelines」をリリースしました。AIモデルはトレーニングデータの「カットオフ日」や古いコードの頻度バイアスにより、時代遅れのGoコードを生成しがちです。このプラグインはgo.modで指定されたGoのバージョンを自動検出し、そのバージョンに対応した最新機能（例：slices.Contains()など）を使うようエージェントに指示します。Junieでは最新バージョンで自動適用され、Claude Codeでは専用コマンドでインストール・有効化できます。
このスライドは「Go Conference mini in Sendai 2026」での発表で、Goにおける nil の仕組みを4つのパートで解説しています。
① nilを言語仕様から見る
nil はキーワードではなく、true や false と同じ「事前宣言された識別子（predeclared identifier）」です。デフォルト型を持たず、pointer・channel・func・interface・map・sliceの6つの型にのみ使えます。また、interfaceだけが内部的に16バイト（2ワード）の構造を持ちます。
② interfaceの内部構造と「nil != nil」
interfaceは内部的に「型情報（*itab）」と「データポインタ」の2つのポインタで構成されます。interface == nil となるのは両方がゼロのときのみです。そのため、nilポインタ（例：*MyError）をerrorインターフェイスに代入すると、型情報が入るため != nil となる「typed nil」問題が発生します。これはGoの仕様通りの動作です。
③ 改善提案の歴史
この問題はGoチームも認識しており、nilptr/nilinterfaceの分離、nullキーワードの導入、zero値の追加、?演算子によるエラーハンドリングの簡略化など、15以上の提案が出されてきました。しかし「Go 1互換性の保証」と設計思想のトレードオフから、いずれも不採用となっています。2025年6月にはエラーハンドリング構文の変更を断念することが公式に表明されました。
④ 実務での付き合い方
独自エラー型や errors.As でのtyped nil混入に注意し、関数の戻り値では必ず明示的に return nil を使うべきです。また、nil channelをselectで活用する設計パターンも有効です。バグ防止には nilaway（Uber）や staticcheck などの静的解析ツールの活用が推奨されています。
株式会社UPSIDERのRyo Mimura氏によるスライドで、AI（LLM）を活用した開発における「速さ」と「治安（コード品質・秩序）」の両立をテーマにしている。
AIによる治安の悪化
AIコーディングツールの普及で実装スピードは飛躍的に向上した一方、古い書き方の量産・既存アーキテクチャ無視・悪癖の増幅など「治安の悪化」が生じやすい。Rules/Skillsといったソフト制約だけでは防ぎきれないため、物理的・機械的に違反を阻むハード制約が必要だと主張する。
アーキテクチャ：依存の制御
Goの internal パッケージによる参照制限や、depguard 等のLintで依存ルール違反をCI段階で検出・遮断する。また「Package by Feature」（ドメイン単位のパッケージ分割）でAIのコンテキストを絞り、精度を高める工夫も紹介。
テスト：AIのハックを防ぐ
AIはテストを「通す」ことに最適化しがちなため、Fuzzing testやMutation testで実装の品質を担保する。実DBを使った結合テスト（testcontainers-go等）も有効で、CIを品質ゲートとして機能させることが重要と説く。
結論
これらは目新しい技術ではなく従来のプラクティスの延長。AIによって実装フェーズが爆速になった結果、ボトルネックがその前後にシフトし、従来の良い開発プラクティスの重要性がむしろ増している。「開発者体験の向上＝エージェント体験の向上」であり、GoはAI時代にも適した言語だとまとめている。
TypeScript 7では、コンパイラの実装言語がTypeScript（JavaScript）からGoに移行し、ビルド速度が最大10倍以上高速化されます。GoはRustより速いからではなく、既存コードベース（関数＋データ構造）の構造がGoのパラダイムと親和性が高く、ゼロからの「リライト」ではなく既存ロジックをそのまま移植する「ポート」が可能だったことが最大の理由です。RustはBorrowチェッカーの制約でリライトが必要になるため却下されました。新コンパイラ（コードネーム: Corsa）はネイティブバイナリとしてgoroutineによる並行処理を活用し、VS Codeプロジェクトで77.8秒→7.5秒を実現。なお、高速化はコンパイル段階のみで、アプリの実行速度は変わりません。
Google Cloud の Telemetry（OTLP）API を使うと、これまで必要だった専用の Cloud Trace Exporter を使わず、標準の OTLP Exporter だけでスパンを Cloud Trace に送信できます。本記事では、Go アプリケーションから OTLP/gRPC でトレースを送る手順を紹介しています。Application Default Credentials（ADC）で認証し、環境変数でプロジェクトを指定するだけで、OpenTelemetry の標準 SDK のままシンプルに Cloud Trace へ送信できることを実際に確認しました。
このブログ記事は、Go言語がメモリ割り当てのパフォーマンス改善に取り組む方法について述べています。
主な内容：
従来、スライスの動的拡張時にヒープ割り当てが繰り返され、ガベージコレクションの負荷が増していました。Go 1.25以降では、コンパイラがスタック上にメモリを割り当てる最適化を自動実行します。
重要な改善：
-
固定サイズスライス（Go 1.24）：サイズが既知の場合、スタック割り当てで0割り当てを実現
-
可変サイズスライス（Go 1.25）：コンパイラが32バイトの小さなバッファをスタックに確保し、必要に応じてヒープにフォールバック
-
append最適化（Go 1.26）：初回append時からスタックバッファを使用。途中でスタック容量を超えた場合のみヒープ割り当てに移行
-
escaping slice最適化（Go 1.26）：関数から返すスライスでも、最終的なコピー時のみヒープ割り当て。複数回の割り当てと削除を避けられます
開発者は手動最適化より、コンパイラの自動変換に頼り、本当に重要な部分に集中できるようになりました。
Golang Codes は、ブラウザ上でGo言語をインタラクティブに学べる無料・オープンソースの学習プラットフォームです。VS Codeと同じMonacoエディタを内蔵しており、コード例をクリックして編集・実行でき、ローカル環境の構築は不要です。変数、構造体、ゴルーチン、チャネル、デザインパターンなど24以上の体系的なレッスンが用意されています。レッスンの受講やコード実行でXP（経験値）を獲得できるゲーミフィケーション要素もあり、学習の進捗を追跡できます。GitHubでのコミュニティ貢献も歓迎されており、エンジニアによるエンジニアのための実践的な学習環境を提供しています。
その他プログラミング
Visual Studio Code
GitHub Copilotの次編集提案（NES）をカーソル付近だけでなく、ファイル内の任意の場所に拡張する機能を開発した。関数のリネームや引数の型変更など、離れた箇所への連鎖的な編集を予測するため、編集箇所を予測する専用の「位置モデル」と、編集内容を生成する既存モデルを組み合わせたマルチモデル構成を採用。過剰なジャンプ提案を防ぐため、強化学習（RLVR）で「ジャンプすべきでないタイミング」も学習させた。A/BテストではNES経由のコード記述量が23%増加。今後はファイルをまたぐ提案や、位置と内容を同時予測する統合モデルの開発を予定している。
VB/VBA
技術界にはExcel/VBAを「古臭い」と見なし、クラウドやRustを「高尚」とする見えないヒエラルキーが存在する。しかし技術の選択は技術力ではなく、現場か管理かという「立ち位置」によって決まる。現場は使える道具で業務改善を実践するが、管理部門はそれを「属人化・シャドーIT」のリスクと捉えてしまう。この対立の根本は、互いの合理性がぶつかる構造的問題だ。解決策として、現場の技術者に管理部門との兼務役割を与える「ハイブリッドな立ち位置」の公認と、技術の種類ではなく「解決の質」を共通言語にすることが提唱されている。
感想:
もともとVBは「プロフェッショナル」向けの開発環境であり、VBAは「エンドユーザーコンピューティング」の手段で、ソフトウェア開発を生業とする人はVB/VBAの対象ではないのです。そもそもRustとはドメインが違う道具なのです。なので、現場の人たちがVBAで日々の業務を効率化していくのは100%正しい。それが邪魔に見えるなら、ITのプロフェッショナルの仕事がちゃんとできていないという事。
.NET
この記事は、C# 14の新機能である「拡張メンバー（Extension Members）」について解説しています。
従来の拡張メソッドと異なり、新しいextensionブロック構文を使用することで、既存の型に対してメソッドだけでなく、インスタンスや静的なプロパティ、さらには演算子も追加可能になりました。これにより、ヘルパーメソッドのプロパティ化や外部APIのより自然な統合が可能になり、コードの整理が容易になります。
Tool
Rustで開発されたCLIツール「md2docx」は、MarkdownファイルをWord形式（.docx）に変換するツールです。既存ツールの課題である図表番号の自動付与に対応し、日本語ビジネス文書作成に特化。游明朝・游ゴシックを標準搭載し、見出しの自動採番やインデント制御をTOML設定で管理できます。手動調整の負担を軽減します。
論文・その他
AIエージェントがSDLCを終わらせた
AIエージェントは開発を「速くした」のではなく、従来のソフトウェア開発ライフサイクル（SDLC）そのものを崩壊させた。要件定義→設計→実装→テスト→レビュー→デプロイ→監視という逐次的なプロセスは、各フェーズが融合し消滅しつつある。
Cursor以降にキャリアを始めたエンジニアはSDLCを知らない。スプリント計画もストーリーポイントもPRレビュー待ちも経験せず、「意図を伝えてエージェントがコードを書き、確認して改善してリリース」というフローで開発している。
各フェーズの変化は明確だ。要件はイテレーションの副産物になり、Jiraはコンテキストストアとして機能不全を起こしている。設計はエージェントとの対話の中で「発見」されるものになった。テストはコードと同時生成され、QAフェーズは消えた。PRレビューはエージェントが1日500件のコードを生成する時代には成立しない。デプロイは継続的かつ自動化され、唯一生き残るのは「モニタリング」だが、それも人間向けのダッシュボードではなく、エージェントへのフィードバックループとして再設計が必要だ。
新しい開発の形は「意図→ビルド→観測→繰り返し」というタイトなループ。SDLCが終わった今、求められる新しいスキルはコンテキストエンジニアリングであり、安全網はオブザーバビリティだと著者は結論づける。
AI
Anthropic
COBOLは米国のATM取引の約95%を処理するなど、金融・航空・行政の基幹システムで今も稼働しているが、開発者の高齢化と大学教育の減少により、理解できるエンジニアが年々減少している。
これまでCOBOLのモダナイゼーションは、数十年にわたる改修で複雑化した業務ロジックの解析に大勢のコンサルタントと数年単位の期間を要し、コスト面から断念されるケースが多かった。
AIの登場はこの状況を一変させる。Claude Codeのようなツールは、①依存関係のマッピング、②誰も覚えていないワークフローのドキュメント化、③移行リスクの自動検出、といったもっとも工数のかかる作業を自動化できる。これにより、従来「数年」かかっていた作業が「数四半期」に短縮される。
実践的な進め方としては、AIが全体を分析して依存関係とリスクを洗い出した後、エンジニアが業務優先度や規制要件を踏まえてロードマップを策定し、1コンポーネントずつ段階的に移行・検証するアプローチが有効だ。人間の判断とAIの自動化を組み合わせることで、信頼性を維持しながら確実に近代化を進められる。
感想:
これでIBMの業績がどうこうというのはどうかしている。投資家が思惑で動くのは仕方がないけど、「エンジニア」を名乗る人間が、これでメインフレームが終わるとか騒ぐのはどうかしているよ。こんな事ぐらいでIBMは終わんないよ。
Anthropic CEOのダリオ・アモデイが2026年2月26日に発表した声明です。AnthropicはAIの国防活用に積極的に取り組んできたが、「大規模な国内監視」と「完全自律型兵器」 の2用途については、民主主義的価値の観点または技術的信頼性の問題から、契約に含めることを拒否している。これに対し米国防総省は、その制限を撤廃しなければAnthropicをシステムから排除し、「サプライチェーンリスク」に指定すると脅迫している。Anthropicはこの要求には応じられないとしつつ、引き続き国防省との協力を望んでいると表明した。
GitHub Copilot
GitHub Copilot CLI、一般提供（GA）開始（2026年2月25日）
GitHub Copilot CLIが、有料Copilotサブスクライバー向けに正式提供開始となりました。2025年9月のパブリックプレビュー以降、数百件の改善を経て、単なるターミナルアシスタントから本格的なエージェント型開発環境へと進化しています。
主な機能：
-
エージェント型開発：複雑なタスクの計画・実行・ファイル編集・テスト実行を自動化。「プランモード」で実装計画を確認してから実行したり、「オートパイロットモード」で完全自律実行も可能。複数の専門エージェントが並列動作します。
-
モデル選択の自由：Claude Opus/Sonnet、GPT-5.3-Codex、Gemini 3 Proなど主要モデルを切り替え可能。セッション中でも
/modelコマンドで変更できます。 -
拡張性：MCPサーバー、プラグイン、カスタムエージェント、スキルファイルなどで機能拡張が可能。
-
レビュー・差分・巻き戻し：
/diffや/reviewでコード変更を確認でき、Esc–Escで以前の状態に巻き戻せます。 -
無制限セッションとメモリ：コンテキストウィンドウの上限に達すると自動圧縮し、セッションをまたいだリポジトリ記憶も保持。
-
エンタープライズ対応：組織ポリシー管理、プロキシ対応、OAuthなど企業向け機能も完備。
Copilot Pro/Pro+/Business/Enterpriseプランで利用可能です。
GoogleのDeepMindは2026年2月26日、最新の画像生成モデル「Nano Banana 2（Gemini 3.1 Flash Image）」を発表しました。
本モデルは、高品質な画像生成で好評を博した「Nano Banana Pro」の高度な機能と、Gemini Flashの高速処理を統合したものです。主な特徴として、Geminiのリアルタイム検索情報を活用した高度な世界知識、マーケティング素材などに使える精確なテキスト生成・多言語翻訳、最大5キャラクター・14オブジェクトの外見を維持できる被写体の一貫性、ユーザーの複雑な指示を忠実に再現する精度の高い指示追従、512pxから4Kまでの多様な解像度・アスペクト比対応などが挙げられます。
Nano Banana 2は本日より、GeminiアプリやGoogle検索（AIモード）、AI Studio、Google Cloud（Vertex AI）、動画制作ツール「Flow」、Google広告など、Googleの幅広いプロダクトに順次展開されます。
さらに、AI生成コンテンツの識別技術も強化されており、SynthIDとC2PAコンテンツ認証情報の組み合わせにより、AI利用の有無だけでなく「どのように使われたか」まで確認可能になります。SynthID検証機能はリリース以来、既に2,000万回以上使用されています。
Perplexity
Perplexity は2026年2月25日、新サービス「Perplexity Computer」を発表しました。
現在のAIモデルは急速に高度化しており、その能力を最大限に引き出すシステムの構築が課題となっていました。Perplexity Computer はその解決策として、あらゆるAI機能を単一のシステムに統合した「汎用デジタルワーカー」です。
ユーザーが達成したい目標を伝えると、システムが自動的にタスクをサブタスクへ分解し、複数のサブエージェントを生成して並行処理を行います。各エージェントはウェブ調査・文書生成・データ処理・API連携などを担い、作業は非同期かつ自動で調整されます。実行環境は隔離されたクラウド上で、ローカル設定不要で利用できます。
特徴的なのは「マルチモデル・オーケストレーション」機能で、用途に応じて最適なAIモデルを自動選択します。推論にはOpus、リサーチにはGemini、画像生成にはNano Banana、動画にはVeo、軽量タスクにはGrok、長文処理にはChatGPTといった形で使い分けます。
現在は Perplexity Max サブスクリプション向けに提供開始されており、近日中に Enterprise Max ユーザーにも展開予定です。
__
標準化
「AIエージェント標準化イニシアティブ」の発表（NIST、2026年2月17日）
NISTのAI標準・革新センター（CAISI）は、AIエージェント標準化イニシアティブの立ち上げを発表した。
AIエージェントは、コード作成・デバッグ、メール・カレンダー管理、商品購入など、自律的なタスクをこなす能力を持つ。しかし外部システムとの相互運用性や信頼性が不十分なままでは、エコシステムの断片化や普及の停滞が懸念される。
本イニシアティブはこの課題を解決するため、以下の3つの柱で推進される。
- 業界主導の標準開発と国際標準機関における米国のリーダーシップ強化
- コミュニティ主導によるオープンソースプロトコルの開発・維持
- AIエージェントのセキュリティとアイデンティティに関する研究推進
NISTは国立科学財団（NSF）などの省庁間パートナーと協力し、公募（RFI）や意見聴取セッションなどを通じて幅広い関係者の意見を収集する。具体的には、AIエージェントセキュリティに関するRFI（締切：3月9日）およびAIエージェントのアイデンティティ・認証に関するコンセプトペーパーへの意見募集（締切：4月2日）が進行中であり、4月からはセクター別の普及障壁に関するヒアリングセッションも開催予定となっている。
エンジニア
脳の調子について
トロント大学の研究者らがScience Advancesで発表した研究によると、日々の認知機能の変動（「メンタル・シャープネス」）が目標達成に大きく影響することが判明しました。184人の学生を12週間追跡調査した結果、「ある日は全認知課題が好調、別の日は全体的に不調」という共通の波が存在し、この波が高い日ほど前日に立てた目標を達成できていることがわかりました。気分ややる気とは独立した要因であり、朝の時点でその日の目標達成ポテンシャルを予測できます。このシャープネスは固定的な能力ではなく、十分な睡眠で向上し、蓄積した疲労で低下するため、「やる気がない」のではなく「その日の脳のコンディションが低い」だけである可能性があります。
OS
Android
Googleは2026年2月、「Android 17 Beta 1」をリリース。例年のDeveloper Previewをスキップし、年2回のSDK更新体制へ移行した。これはAIの進化速度にOSを追従させるためで、AIエージェントのモバイル実装を加速させる狙いがある。新機能「Handoff」でスマホの作業を別デバイスへシームレスに引き継げるようになり、オンデバイスAI基盤「AICore」の活用も深化。また、Android 17をターゲットとするアプリは大画面での画面回転・サイズ制限が禁止され、レスポンシブデザインが必須となった。OSはAIと人間が協調して操作するプラットフォームへと再定義されつつある。
UX・システム: アプリをフローティングウィンドウで表示できる「Bubbles」機能、画面上の任意ピクセルから色を取得できる「EyeDropper API」、プライバシーを保護した連絡先ピッカーなどが追加されました。
接続・クロスデバイス: 近くのAndroidデバイスへアプリの状態を引き継ぐ「Handoff API」や、UWBを活用した屋内ナビゲーション対応の「高度測距API」が導入されました。
プライバシー・セキュリティ: ローカルネットワークアクセスに新たな実行時権限が必要になり、SMSのOTP保護が強化（ほとんどのアプリで3時間の遅延アクセス）されました。
Platform Stabilityは3月を目標としており、一般公開はその後数か月後の予定です。
Discussion
記事引用いただきありがとうございます😊