Alti blog

(実験サイトでのブログなのでサイトが落ちてたらごめんなさい)

  • 石破首相の辞任を受けて今後の予定と予想をAIに解説してもらった

    ニュースを見ても、今後の予定などが良く分からなかったので、AIに解説してもらいました。

    今後の予定と予想:石破首相辞任を受けて

    主なポイント

    1. 臨時閣議・閣僚改造の可能性
      • 首相辞任後、臨時の閣議を開催し組閣(内閣改造)や官邸人事の調整が行われる見込み。
      • 特に自民党内での派閥均衡や選挙対策を重視した人事が焦点となる。
    2. 自民党総裁選
      • 次期首相を決める自民党総裁選が10月中旬〜下旬に実施される可能性が高い。
      • 立候補受付は9月下旬、投開票は10月第3週前後と想定。
      • 各候補は党所属議員票と党員票の獲得を巡り調整を急ぐ。
    3. 衆議院解散・総選挙の行方
      • 解散時期は総裁選後、11月〜12月に断行される可能性が取り沙汰されている。
      • 秋の臨時国会(10月20日召集予定)での与党提出法案の通過状況を見て判断。
      • 野党との攻防や世論動向、経済指標の悪化が早期解散の材料となる可能性。
    4. 立候補が予想される主要候補
      • 岸田文雄前首相:実績重視派からの支持根強い。
      • 高市早苗元政調会長:保守強硬派が推す。
      • 河野太郎前防衛大臣:実務派として注目。
      • 茂木敏充元外相:調整役として名前が浮上。
    5. 与野党の攻防と世論動向
      • 与党内では新リーダー像をめぐり派閥調整が激化。
      • 野党は憲法改正・物価高対策を争点化し、支持拡大を狙う。
      • 世論調査では政府支持率の低下傾向があり、次期選挙での与党苦戦も予想。

    首相辞任を契機に、10月中旬の自民党総裁選→臨時国会→解散・総選挙という流れが想定される。内部調整の行方と経済・外交情勢が今後のカギとなる。


    いつまで、石破首相は首相のポジションに就きますか?

    石破首相は、正式に辞意を表明した後も、新しい自民党総裁が選出され、国会での首班指名を経て後任が組閣するまでの「臨時首相(caretaker)」として職務を継続します。現時点で見込まれているスケジュールをまとめると次のとおりです。

    1. 9月下旬~10月上旬 ・自民党総裁選の立候補受付開始・党内調整
    2. 10月中旬 ・党員投票・国会議員投票による総裁選投開票
    3. 10月下旬 ・新総裁による首班指名(特別国会または臨時国会) ・新内閣の閣僚任命式

    つまり、石破首相は新総裁・新内閣が発足する10月下旬頃まで、首相の地位にとどまる見込みです。


    AIを活用した気づき

    次の総裁や内閣総理大臣が決まるまでは、「臨時首相」 として、職務を継続するんですね。各社のニュースだけだと分からなかったので、学びになりました。

  • 【2025年9月版】SNSで動画マーケティングを始めるにあたっての1つだけデバイスを選ぶなら

    最近相談頂いたので、こちらをブログ記事にしてみました。

    まずスマートフォンの最新化が初手と考えています。 既に新しいものをお持ちの方もいるかもしれませんが、相談される方が古めのスマートフォンを使っている可能性を踏まえると、1デバイスで色々とこなすには、まずは「最新のスマートフォン」というのが妥当かと考えています。

    では、「動画マーケティング」をする上での「最新のスマートフォン」の定義をしておくと、

    「インカメラ(前面カメラ)でも4K動画が撮影できる」

    となります。

    スマートフォンは、カメラのスペックは通常は普段主に撮影する方の「背面カメラ」の方が高いスペックとなっていますが、動画マーケティングに1デバイスで挑む場合は、

    • もちろん高画質で撮影をする
    • 原稿もスマートフォンで表示しつつ (できるだけカメラ目線に近づけて)
    • カメラ映りを自分で確認しつつ撮影

    ができる必要があります。

    そのため、「背面カメラ(メインカメラ)」のスペックではなく、「インカメラ(前面カメラ/フロントカメラ)」のスペックに拘る必要があります。

    分かりやすく「スペック検索」で見つけられるかなと思い 価格.com – スマートフォン スペック検索・性能比較 を見てみたのですが、ちょっと分かりやすく検索ができなかったので、AI検索などを活用したところ、こちらの情報 「スマホでここまで撮れる?」カメラ性能ガチの神モデル5選【2025年】|今日のいいモノ発見隊 が参考になりました。

    少し古いので、Google Pixelの紹介は、最新の 10 Pro ではなく、9 Pro になっておりました。 記事には、

    lInstagramやYouTubeショートなどSNS向けなら?Google Pixel

    とあり、最新に置き換えて、画面が6.5インチ以上でiPhoneとGoogle Pixelで価格も含んで比較してみます。

    製品 価格帯 その他
    iPhone 16 Pro Max 約19万円前後~ iMovieなどAppleエコシステムの恩恵が受けられる。Adobe Premiere iPhone版アプリは期待大
    Google Pixel 10 Pro XL 約19万円前後~ Google AIのエコシステムの恩恵が受けやすい。
    Google Pixel 10 Pro Fold 約27万円前後~ 画面がほぼ倍大きく使える。Google AIのエコシステムの恩恵が受けやすい。※発売は来月2025年10月

    では、どう考えるか?

    普段使いのパソコンが、Macの方は、iPhoneで良いと思います。動画編集にiMovieという無料で使いやすいものが選べます。また、Androidより先行して、プロユースの動画編集アプリのモバイル版がAdobe Premiere iPhone版として先行することが アナウンス されるされているので、Apple製品で固めておくことで、まずはコスパが良さそうです。

    普段使いのパソコンが、Windowsの方は、Google製品に軍配が上がります。 まずスマートフォンにかけられる予算が普通の方は、Google Pixel 10 Pro XL が宜しいかと思います。 GoogleのAI製品のエコシステムの恩恵が受けやすい面と価格のバランスが優れいているからです。

    次に、スマートフォン用の予算が多めにかけられるならという条件付きとなりますが、Google Pixel 10 Pro Fold という通常のスマートフォン2画面分の大画面を持ったスマートフォンでは、動画撮影・編集・SNS運用の全ての面において恩恵を受けやすいかもしれません。もちろん普段使いとしては重量がちょっと重くなるので、そこの辛さはあります。

    上記参考にご検討ください!

  • 【勝手翻訳】Linearは私をローカルファーストのウサギの穴に導いた

    Linear sent me down a local-first rabbit hole | Bytemash の記事が興味深ったので、少しまとめました。

    動機

    Linearは信じられないほど高速なプロジェクト管理ツールで、ネットワークの遅延はどこにあるのでしょうか?競合はどのように処理されているのでしょうか?オフラインになるとどうなるのでしょうか?と疑問に感じて調べたそうです。

    ウサギの穴に落ちる

    簡単に言うと、彼らはブラウザのIndexedDBを実際のデータベースとして扱う独自の同期エンジンを構築しました。すべての変更はまずローカルで行われ、その後バックグラウンドでGraphQLによる変更とWebsocketによる同期が行われているそうです。

    データベースをクライアントに移動することで、ユーザーインタラクションパスにおけるネットワーク遅延が排除されることです。更新はローカルデータベースの読み取り/書き込みのみなので、瞬時に実行されます。

    課題:これは簡単なことではない

    Linearのアプローチを理解した後、私の最初の直感は似たようなものを作ることでした。しかし、現実が突きつけられました。彼らの同期エンジンの基本バージョンでさえ、おそらく数ヶ月のエンジニアリング作業が必要だったのです。

    複雑さの原因は次のとおりです。

    • オフライン/オンラインの移行を適切に処理する
    • 分散クライアント間の競合解決
    • 部分的な同期(データベース全体をダウンロードしたくない)
    • キャッシュされたデータ間のスキーマ移行
    • 分散システムにおけるセキュリティとアクセス制御
    • きっと誰かがすでにこの魔法を再利用できるものに組み込んでいるのでしょう…

    2025年のローカルファーストエコシステム

    幸いなことに、地域を第一に考えるコミュニティが解決策を構築してきました。現在の状況は次のとおり調査したそうです。

    生産準備完了オプション

    • Electric SQL – Postgres ベースの同期エンジン
    • PowerSync – エンタープライズ向けソリューション
    • Jazz – 私の目に留まったもの (下記参照)
    • Replicache – The OG (RIP)
    • [Zero](https://zero.rocicorp.dev/( – Replicacheチームの新しいアプローチ
    • Triplit – TripleStoreベースの同期
    • Instant – 開発者エクスペリエンスに重点を置く
    • LiveStore – 電力会社やその他のプロバイダー向けのリアクティブレイヤー

    深掘り:Jazz

    Jazz と Zod で構築されたスキーマから始めます。これらが単なる型定義ではなく、自動的に同期するライブで反応的なオブジェクトである点です。APIルートも、リクエスト/レスポンスのサイクルも、DTOもありません。ただ…魔法のように同期するオブジェクトだけ。

    ローカルファーストが意味を成すのはいつでしょうか?

    ローカル ファーストを調べ、Jazz を試した後、このパラダイムがどのような場合に適するかについて次のような印象を受けました。

    優れたフィット感:

    • クリエイティブツール(デザイン、ライティング、音楽)
    • 共同作業アプリケーションまたは大規模なアプリケーションの要素
    • オフラインサポートが必要なモバイルアプリ
    • 開発者ツール
    • 個人の生産性向上アプリ

    挑戦的なフィット感:

    • 重いサーバーサイドビジネスロジック
    • 厳格な監査要件
    • 大規模分析
    • 深く統合された既存のシステム
    • リクエストがサーバー側のロジックによって定期的に拒否されるシステム(楽観的な更新が困難になる)

    楽しみにしている

    ローカルファーストは、アプリケーション構築方法に根本的な変化をもたらします。ユーザーエクスペリエンスのメリットは紛れもなく、Linearがそれを証明しました。問題は、アーキテクチャ上のトレードオフが、あなたのユースケースにとって価値があるかどうかです。

    これらのトレードオフを実際に理解するために、Jazzを使って個人用アプリケーションを開発しています。開発体験は驚くほど新鮮ですが、抽象化が漏れている箇所を注意深く見守っています。

    エコシステムはまだ若い。ツールは成熟し、パターンが生まれ、鋭いエッジは滑らかになるだろう。しかし、データをローカルに保つことでユーザーエクスペリエンスを劇的に向上させることができるという、核となる洞察は消えることはない。

    何か新しいものを構築していて、制約内で作業できる場合は、ローカルファーストを試してみることをお勧めします。最悪のケースでは、新しいアーキテクチャパターンを習得することになります。最良のケースでは、ユーザーにとって信じられないほど高速に感じられるものを構築できるでしょう。

    応答時間が 300 ミリ秒の世界では、これは利点となります。

    まとめ

    ブラウザのIndexedDBにデータを持たせて、ユーザー体験を素早いものにしつつ、サーバ側/クラウド側に裏で同期して、整合性を持たせる。というアーキテクチャは今後増えていきそうですね。

  • 【勝手翻訳】[RooVetGit/Roo-Code] Release v3.23.14

    ソース: Release Release v3.23.14 · RooCodeInc/Roo-Code

    [3.23.14] – 2025-07-17

    • API によって開始されたタスクを tmp ディレクトリに記録する
  • 【勝手翻訳】[RooVetGit/Roo-Code] Release v3.23.13

    ソース: Release Release v3.23.13 · RooCodeInc/Roo-Code

    [3.23.13] – 2025-07-17

    • プロンプトの変更を「元に戻す」機能を追加
    • LiteLLMプロバイダのベースURLのパスコンポーネントにパスが含まれているバグを修正(@ChuKhaLiさんに感謝)
    • Claude CodeをVertex AIで使用する際に、Vertex AIモデル名のフォーマットをサポート(@janaki-sasidharさんに感謝)
    • list-filesツールには、少なくとも第1階層のディレクトリの内容が含まれている必要があります(@qdaxbさんに感謝)
    • 連続エラーとツールの繰り返しの両方を制御する設定可能な制限を追加(@MuriloFPさんに感謝)
    • チェックポイント除外パターンに.terraform/および.terragrunt-cache/ディレクトリを追加(@MuriloFPさんに感謝)
    • Ollama APIのタイムアウト値を増加(@daniel-lxsさんに感謝)
    • 設定変更がない場合でも、保存前に「変更を破棄」する必要がある問題を修正
    • DirectoryScannerのメモリリークを修正し、ファイル制限の処理を改善(@daniel-lxsさんに感謝)
    • 環境設定(@chrarnoldus さん、ありがとう)
    • 空のモード名が保存されないようにしました(@daniel-lxs さん、ありがとう)
    • 自動承認チェックボックスのUXを改善しました
    • チャットメッセージの編集/削除機能を改善しました(@liwilliam2021 さん、ありがとう)
    • GlobalSettings に commandExecutionTimeout を追加しました
  • 【勝手翻訳】[backstage/backstage] Release v1.41.0

    ソース: Release v1.41.0 · backstage/backstage

    v1.41.0

    Backstage v1.41.0 リリースのリリースノートです。

    このリリースの開発と完成に尽力いただいた、メンテナーとコントリビューターのチーム全員、そして素晴らしい Backstage コミュニティの皆様に深く感謝いたします。

    ハイライト

    速報:カタログバックエンド 3.0 – 新しいデフォルト

    カタログプラグインバックエンドのこのメジャーリリースでは、カタログの動作に影響を与えるいくつかのフラグのデフォルト値が変更されました。 #30546

    catalog.orphanStrategy がデフォルトで削除されるようになりました これにより、デフォルトの孤立戦略が、カタログ内で参照されなくなったエンティティを積極的に削除するように切り替わります。

    このフラグは、移動または削除されたエンティティをクリーンアップする方法として何度も提案されており、これをデフォルトで有効にするのが良いタイミングだと考えています。

    設定で orphanStrategy: keep を指定することで、以前の動作に戻すことができます。

    catalog.orphanProviderStrategy がデフォルトで削除されるようになりました。 これにより、デフォルトのプロバイダインストール戦略が変更され、存在しなくなったプロバイダのエンティティは保持されなくなります。

    過去にインストールしたプロバイダが、保持したいエンティティをカタログに取り込んでいた場合は、そのプロバイダをカタログに再度追加することをお勧めします。プロバイダの実行を中止したい場合は、非常に長い間隔でスケジュールを設定できます。

    catalog.disableRelationsCompatibility がデフォルトで有効化 リレーション互換性がデフォルトで無効化されました。新しい enableRelationsCompatibility フラグで再度有効化できますが、カタログ全体のパフォーマンスが大幅に低下する点にご注意ください。

    リレーション互換性により、カタログレスポンスのリレーションオブジェクト内に targetReftarget の両方が含まれるようになります。無効化されている場合は、targetRef のみが含まれます。targetRef への移行は何年も前に導入されたため、Backstage エコシステムでは長い間 target は必要ありませんでした。したがって、この変更の影響を受けるのは、カタログを利用する外部のカスタムコンシューマーのみです。

    catalog.stitchingStrategy はデフォルトで { mode: 'deferred' } になりました。 スティッチングは、エンティティをカタログに取り込む最終段階です。個々のエンティティに関連するすべての情報を収集し、エンティティの完全な出力バージョンを生成して、読み取り API を実行するテーブルに書き込みます。

    これにより、スティッチングはメインのカタログ処理ループではなく、バックグラウンドタスクで非同期的に実行されるようになります。これにより、大規模なカタログでのスティッチングのパフォーマンスが大幅に向上します。

    catalog.useUrlReadersSearch が常に有効になりました 1.36 で追加された catalog.useUrlReadersSearch フラグが削除され、常に有効になりました。つまり、カタログ内の UrlReaderProcessor は、場所を読み取る際に read メソッドではなく、常に search メソッドを使用します。これにより、個々の URL リーダーは、場所が単一のファイルを参照しているのか、それとも検索が必要なワイルドカードなのかを判断できます。

    この重大な変更は、カタログで使用するためにカスタム URL リーダーをインストールしている場合にのみ影響します。これらのリーダーが既に正確な位置から読み取れる検索メソッドを実装している場合は準備完了です。そうでない場合は、以下のように更新する必要があります。

    search(url, options) {
      if (!isWildcard(url)) {
        return this.readUrl(url, options)
      }
      // 既存の検索ロジック、またはワイルドカードがサポートされていない場合は例外をスロー
    }

    @tcardonne による #29788 への貢献

    重大な変更: Scaffolder の権限の変更

    Scaffolder のアルファ版権限ルールの一部に、重大な変更が加えられました。

    タスクの再試行には、以前は scaffolder.task.readscaffolder.task.cancel の両方が必要でしたが、現在は scaffolder.task.readscaffolder.task.create の両方の権限が必要になりました。

    scaffolder.task.readscaffolder.task.cancel に新しい scaffolder ルール isTaskOwner を追加しました。これにより、タスク作成者に基づいてタスクやタスクイベントへのアクセスを制限するなどの条件付き権限ポリシーが可能になります。

    また、scaffolder.task.readscaffolder.task.cancel をリソース権限に変換しました。

    #29202 で @04kash が貢献しました。

    Canon から Backstage UI への名称変更

    Backstage の新しいデザインシステムである Canon の名称を Backstage UI に変更することを決定しました。この変更の詳細については、デザインシステム RFC のこちらのコメントをご覧ください。この変更の一環として、@backstage/canon@backstage/ui に、canon.backstage.ioui.backstage.io に変更されます。

    Backstage Yarnプラグインによる backstage:^ バージョンの自動生成

    backstage:^プロトコルを使用して、yarn が新しいBackstage依存関係をインストールできないバグを修正しました。🎉

    #30390で@eipc16が貢献しました。

    セキュリティ修正

    このリリースにはセキュリティ修正は含まれていません。

    アップグレードパス

    Backstageプロジェクトをこの最新リリースにアップデートすることをお勧めします。アップグレード方法の詳細については、Backstageを最新の状態に保つためのドキュメントをご覧ください。

    リンクと参考資料

    以下に、この新しいリリースについて学び、使い始める際に役立つリンクと参考資料のリストを示します。

    Backstage の最新情報を受け取りたい場合は、ニュースレター にご登録ください。

  • 【勝手翻訳】[RooVetGit/Roo-Code] Release v3.23.12

    ソース: Release Release v3.23.12 · RooCodeInc/Roo-Code

    [3.23.12] – 2025-07-15

    • モデルパラメータの最大トークン計算を更新して、Kimi K2 などをより適切にサポートします。
  • 【勝手翻訳】[RooVetGit/Roo-Code] Release v3.23.11

    ソース: Release Release v3.23.11 · RooCodeInc/Roo-Code

    [3.23.11] – 2025-07-14

    • GrowにKimi K2モデルを追加し、コンテキストコンデンシングの計算を修正しました。
    • 前のモードに切り替えるためのCmd+Shiftキーのキーボードショートカットを追加しました。
  • 【勝手翻訳】[RooVetGit/Roo-Code] Release v3.23.10

    ソース: Release Release v3.23.10 · RooCodeInc/Roo-Code

    [3.23.10] – 2025-07-14

    • 組み込みモデルディメンションをカスタムディメンションよりも優先します (@daniel-lxs さん、ありがとうございます!)
    • インデックスモデルオプションにパディングを追加します
  • 【勝手翻訳】[RooVetGit/Roo-Code] Release v3.23.9

    ソース: Release Release v3.23.9 · RooCodeInc/Roo-Code

    [3.23.9] – 2025-07-14

    • Claude Code プロバイダーを Windows でネイティブに実行できるようにしました (@SannidhyaSah さん、ありがとうございます!)
    • gemini-embedding-001 モデルを code-index サービスに追加しました (@daniel-lxs さん、ありがとうございます!)
    • 埋め込みモデルの切り替え時に発生するベクトル次元不一致エラーを解決しました
    • exec ツールのレスポンスで cwd を返すようにしました。これにより、後続の呼び出しでモデルが失われることはありません (@chris-garrett さん、ありがとうございます!)
    • VS Code 設定でコマンド実行のタイムアウトを設定できるようになりました