  |
はてなキーワード: TPMとは
ファーウェイが初の独自OSパソコン キーボード部分も全面有機EL
https://www.nikkei.com/article/DGXZQOGM198JT0Z10C25A5000000/
もし現代に0からOSを作成する場合、これらのOSの技術的負債や欠点を教訓として設計するならどのようなものが考えられますか？
| 観点 | Linux で顕著 | Windows で顕著 | 共通課題 |
|---|---|---|---|
| カーネル構造 | 巨大モノリシック ＋ 常に ABI が流動的（外部モジュール苦労） | 歴史的にモノリシックに近く高密度・複雑 | 信頼境界が広く、脆弱性が権限昇格に直結 |
| 安全性 | Unix-型「ユーザー/グループ + SUID」が限界 | ACL/SID が複雑化・分散 | “一発 root/SYSTEM” を許すモデル |
| ドライバ | OSS/ベンダ混在・署名不足・上流統合が負担 | 内部 API 長期固定の重荷、古い HW サポートが尾を引く | カーネル空間に巨大コード |
| 更新 | ディストロごとに仕組み相違、再起動依存 | 累積パッチ巨大・Reboot 必須 | 取替え可能性 ≈ 可用性低下 |
| ユーザー空間 | バイナリ互換よりソース互換優先で「壊れやすい」 | DLL Hell / COM 登録 Hell | グローバル名前空間汚染 |
| 設定管理 | /etc + 点在 config → 形式・権限バラバラ | Registry 巨大モノリス → 腐敗 | アトミックではない変更が多発 |
| 開発プロセス | メーリングリスト文化でレビューボトルネック | 閉鎖的で古いコード維持不可避 | 純粋なモジュール性が欠如 |
マイクロカーネル（あるいは hybrid microkernel）＋ ユーザー空間ドライバ。
カーネル定義の “secure capability” ハンドルのみを他プロセスへ授与。
seL4 や Fuchsia の Zircon が示す「検証可能サイズ」を目標に。
| 観点 | デメリット | 旧 OS が採用しなかった背景 |
|---|---|---|
| 性能 | コンテキストスイッチと IPC が頻発し、90 年代 CPU では大きなオーバーヘッド。 | ハードウェア性能が不足し、リアルタイム性やスループットを優先した結果、モノリシック構造に。 |
| 実装コスト | OS サービスが分散し、デバッグやトレーシングが煩雑。 | 完全分離を行うツールチェーン／デバッガが未成熟だった。 |
| ドライバ移植 | ユーザー空間化で ABI は安定するが、低レイテンシ要求デバイス（GPU など）の処理が難しい。 | 当時は “音声が途切れる” 程度でも市場競争力を失うためカーネル内に残す決断。 |
Rust や Zig のような safe systems 言語。
C 部分は必要最低限に隔離し、unsafe 領域は形式検証 / fuzz 前提。
| デメリット | 背景 |
|---|---|
| ランタイム負荷 言語ランタイムを最小に削る必要があり、一部 unsafe が不可避。 | 70〜90 年代は C 以外に bare-metal 向け安全言語が事実上存在せず。 |
| コンパイラ信頼性 コンパイラ自身の欠陥がカーネル欠陥に直結。 | “自己ホスト” 安全言語を実機に載せる環境が不足。 |
| 学習コスト OSS/商用エコシステムが C 前提で巨大。 | ドライバサンプル・書籍・人材が C/C++ に集中していた。 |
外部インタフェース（syscall, driver ABI）は長期安定。
その裏で内部サービスは gRPC/FlatBuffers 相当の IDL で世代管理し交換可能。
| デメリット | 背景 |
|---|---|
| 進化速度の拘束 ユーザ空間から見える syscall を変えにくい。 | MS-DOS 互換・Unix 互換という既存ソフト資産が最重視された。 |
| バイナリサイズ肥大 旧世代 ABI を残すため “脂肪” がたまる。 | ストレージ単価が高く「後方互換より容量削減」が優先された時期が長い。 |
アプリは原則 container-like sandbox（Wasmtime, OCI など）で実行。
ファイルシステムは per-app の仮想 Namespaces、権限委譲は capability passing。
| デメリット | 背景 |
|---|---|
| 複雑な権限委譲 ファイルダイアログすら Capability 伝搬を要し、開発者負担。 | “単一 PC＝単一ユーザー” が前提で、砂箱の必要性が薄かった。 |
| 互換レイヤ 既存ネイティブアプリを仮想化するとパフォーマンス低下。 | RoM の小規模ゲームですら速度が死活問題だった 80～90 年代。 |
A/B partition や OSTree 型 “全イメージ” 交換。
任意時点へ atomic rollback；カーネル更新も Live-patchable。
| デメリット | 背景 |
|---|---|
| ストレージ消費 OS イメージを常時二重に保持。組み込みでは致命的。 | HDD が高価・遅い、SSD がない時代には非現実的。 |
| アップデート粒度 小パッチ配布より帯域を食う。 | ダイヤルアップ回線や CD リリースが主流で “差分パッチ” が合理的だった。 |
systemd-や Kubernetes-風の “状態 = 宣言” を1か所に。
| デメリット | 背景 |
|---|---|
| 学習曲線 既存の `vim /etc/xxx.conf` 流儀や regedit から大きく変わる。 | 管理者層が “設定＝テキスト or レジストリ” に慣れ切っていた。 |
| 複雑なマイグレーション 全サービスが同時に対応しないと一貫性が壊れる。 | OSS は分散開発で統一仕様を打ち立てる強権がなかった。 |
ベンダーは署名した “driver capsule” をリリースするだけ。
| デメリット | 背景 |
|---|---|
| パフォーマンス JIT / interpreter を挟むぶんネイティブより遅い。 | 当時 JIT 技術が未成熟で、リアルタイム I/O を捌けなかった。 |
| ハード依存 API DMA や割込みの抽象化が難しく、結局 “逃げ” でネイティブ部が残る。 | 旧 OS ではベンダがアセンブリ最適化で差別化していた。 |
ユーザー空間 API は async/await; カーネルはメッセージ転送中心。
NUMA・GPU・FPGA などヘテロ資源を first-class に。
| デメリット | 背景 |
|---|---|
| コード複雑化 async/await で “状態機械” を書けないとデッドロックを誘発。 | 90 年代はシングルコア前提で同期 API が単純・高速だった。 |
| デバッグ困難 スタックトレースが非同期に飛び、ツールチェーンが未整備。 | OS デバッガ/プロファイラがプリエンプティブスレッド中心に設計されていた。 |
Capability + Labels (MAC) + Hardware root-of-trust (TPM, DICE) を統合。
| デメリット | 背景 |
|---|---|
| ポリシー設計負担 SELinux でも “設定が難し過ぎて結局無効化” が多発。 | 当時はネット接続率が低く、ローカル攻撃ベクトルのリスク認識が薄かった。 |
| 互換問題 古いアプリが過剰特権を要求し、制御を有効にすると動かない。 | 商用ソフト対応を優先し無効化せざるを得なかった。 |
すべての公式バイナリは reproducible build エビデンスと SBOM 付与。
脆弱性スキャンと revocation を OS レイヤが自動化。
| デメリット | 背景 |
|---|---|
| ビルドパイプライン整備コスト 全パッケージを byte-identical に再現するにはツール統制が必要。 | オープンソース文化自体が黎明期で、ビルド環境を標準化する動機も手段も希薄。 |
| 秘密ロジック公開の葛藤 一部ベンダはソースハッシュ公開を嫌がる。 | IP 保護が優先され、署名のみ・SBOM なしがデファクトだった。 |
User Apps (Wasm / OCI Sandboxes) ------------------------------------- │ Capabilities ▼ Services ──▶ Driver Svcs(user-space) (Pkg, GUI, FS) ------------------------------------- │ syscalls = message send / recv (stable ABI) ▼ Microkernel ~100 kLoC, memory-safe (sched, vm) ------------------------------------- │ Secure IPC (SMC / VTL) ▼ Hypervisor(optional, for legacy guests / composable sandboxes)
Legacy Compatibility は Type-2 ハイパーバイザで提供し、歴史的 API を隔離。
UI Stack もユーザー空間サービスとしてホットリロード可。
Policy Engine で JSON/YAML 宣言→バイトコードへ compile、ランタイム適用。
| 教訓 | 新 OS プロジェクトでの対策 |
|---|---|
| Linux: 大規模パッチはレビューパンクする | GitHub PR + 公式 LTS gatekeeper、CLA & コーディング規約を機械検証 |
| Windows: Close-source で内部知識が属人化 | 100% open-design、Spec⇄Impl 双方向ドキュメント、自動生成 |
| 両者: “一社主導 vs 実質無政府” の二極端 | 財団モデル (Rust, Cloud Native) で技術運営と商用版の両輪 |
これらを先天的に組み込むことで、Linux/Windows が数十年かけて抱えた技術的負債（巨大特権領域・ABI拘束・設定の散逸・更新の非原子性 etc.）を回避しながら、クラウド・エッジ・IoT・AI アクセラレータ が混在する 2020-30年代以降の計算環境に即した OS が実現できます。
国家プロジェクトれべるだわ
俺たちのパソコンが、いつも「古い」とか「使えんようになった」って言われるのは、実は企業側がわざとそういう仕組みを作り出しているからである。たとえば、Windows 11のリリース時に、TPM 2.0必須や最新CPUしか動かんといった、技術的に見れば問題なく使えるパソコンにも無理なスペック足切りを課す。これによって、実際には十分な性能を持つパソコンが、あたかも使えへんゴミのように扱われ、消費者は新しいパソコンを買わされるラットレースに参加させられるのだ。
このような強引な需要創出の仕組みは、企業が売上を伸ばすための戦略であり、俺たちが自分の都合でパソコンを使う自由を奪っている。企業は、最新OSに対応しなきゃ安心できん、便利にならんといった幻想を植え付け、実際には問題ないはずのパソコンを、あたかも「時代遅れ」だと決めつける。それにより、無理やり新しい製品に買い替えさせることで、売上を確実なものにしようとしているのである。
さらに、この需要喪失を満たすために、企業は無意味な仕事、すなわちブルシットジョブを次々と生み出している。デヴィッド・グレーバーが指摘したように、「まるで誰かが、全員を働かせ続けるためだけに無意味な仕事を作り出しているかのようだ」という状況が、現実のPC業界にもある。新OSの導入に伴って、マーケティングやサポート、管理といった、本来は必要ないはずの職務が増え、働く人々はその無意味さを感じながらも、企業の策略に沿って受動的にラットレースに参加させられているのだ。
こうして、俺たちは実際には自由にパソコンを使えるはずなのに、企業が仕掛ける強引な需要創出と、それに伴うブルシットジョブのせいで、自分の都合で使う権利を奪われ、無駄な買い替えとアップグレードのサイクルに巻き込まれているのである。結果として、俺たち消費者は、企業のレント・シーキング戦略、すなわち新たな富を生み出すことなく既存の富を拡大するための手法に、金をむしり取られている状態にあると言える。
この現状を知れば、俺たちは自分たちの本当の使い方、つまり必要なときに自分の都合でパソコンを使える自由が、企業の策略によって奪われているということに気づかざるを得ない。企業は、自らの利益を守るため、無意味なアップグレードとそれに伴うブルシットジョブを通じ、俺たちの財布から無駄な出費を引き出し続けているのだ。これが、PC買い替えやOSアップグレードのラットレースに参加させられる理由であり、俺たちが自分の都合でパソコンを使う自由を奪われる根本的な原因であるといえる。
現代のPC業界におけるアップグレードサイクルは、企業が自らの利益を守るために意図的に仕組んだものである。企業は新OSをリリースするたびに、実際には十分に機能するパソコンに対して、あたかも「古い」ものであるかのようなレッテルを貼り、消費者に新しいパソコンへの買い替えを強いる。この現象は、人類学者のデヴィッド・グレーバーが「無意味な仕事（ブルシット・ジョブ）」について述べた論理と酷似している。すなわち、まるで誰かが、全員を働かせ続けるためだけに無意味な仕事を作り出しているかのようである。企業は、アップグレードに伴うマーケティング、サポート、管理などの無意味な業務を増やすことにより、自らの既存の富を増やす（レント・シーキング）戦略を実行しているのである。
ジョン・メイナード・ケインズがかつて、技術進歩によって15時間労働週が実現すると予言したにもかかわらず、現実にはむしろ技術は我々全員をより多く働かせるために利用される結果となった。これは、PC業界においても同様である。最新のOSを導入するための高いハードウェア要件（例えばTPM 2.0必須や最新CPUの搭載など）は、技術的な制約ではなく、企業が自らの利益を最大化するために設定されたものである。こうして、技術的には十分に性能を発揮できるパソコンが、企業の都合であたかも使えない古いものとして扱われる。その結果、消費者は不要な買い替えを余儀なくされ、企業はそのたびに新たな収益を得るとともに、無意味な仕事が膨らんでいく。
グレーバーが示したように、現代社会は、まるで誰かが無意味な仕事を作り出して、みんなを働かせ続けるためだけのシステムに陥っている。実際、PCのアップグレードサイクルによって、企業のマーケティング担当者、サポートスタッフ、管理部門といった、もともと必要なかったであろう職務が次々と生み出されている。これらのブルシット・ジョブは、社会全体の資源を無駄にし、経済の効率性を低下させる原因となっている。また、このような戦略は、消費者が本来持つべきコンピューティングの自由をも奪っている。実際のところ、パソコンは何年も使い続けることが可能であり、単に最新OSに対応しなくなったからといって、急いで新しいパソコンに買い替える必要はないのである。
さらに、こうした企業の戦略はレント・シーキングの一環である。レント・シーキングとは、新たな富を生み出すことなく、社会的または政治的な環境を操作することで、既存の富を増やす行為である。企業は、最新OSや新型パソコンの必要性を強調することで、消費者に無駄な出費を強い、結果としてその余分な費用を自らの利益として取り込んでいるのである。このような手法は、資源の誤配分や競争の阻害、さらには所得格差の拡大など、社会全体にとって望ましくない影響を及ぼすものである。
この状況に対して、ひとつの合理的な対策として注目されるのがLinuxである。Linuxは、最新OSが要求するような無意味なハードウェアスペックに縛られることなく、古いパソコンでも十分な性能を発揮する。例えば、中古のThinkPadにLinuxをインストールすれば、Web閲覧、文書作成、プログラミング、動画視聴などの基本的な作業において、最新のパソコンと大差なく使うことが可能である。さらに、かつて「デスクトップLinuxは使いにくい」と言われたが、現代のLinuxディストリビューションはGUIが整備され、初心者でも容易に扱えるレベルにまで進化している。これにより、企業が仕掛ける「捏造された古さ」や無意味なアップグレードサイクルから解放され、消費者は余計な出費や無意味な労働負担を回避することができる。
総じて、現代のPC業界は、企業が自らの利益を守るために、必要以上のアップグレードを強制し、その結果としてブルシット・ジョブを生み出し、レント・シーキングを通じて無駄な出費を消費者に負担させる仕組みとなっている。私たちは、この現状を冷静に理解し、企業の策略に惑わされることなく、Linuxのようなオープンなソリューションを選択することで、本来あるべきコンピューティングの自由と効率を取り戻すべきである。
「Windows 11が動かない？そろそろ買い替え時ですかね〜」
こんなセリフを口にして、電気屋の「お買い得！最新モデル！」コーナーに吸い込まれていく哀れな消費者たち。お前たち、まんまと企業の策略にハマっているぞ。
冷静になれ。お前たちに必要なのは中古のThinkPad だ。
Microsoftが新しいWindowsを出すたびに、何が起こる？
「新しいOSはより安全で快適！」と謳いながら、突然「TPM 2.0が必要です」「このCPUはサポートされていません」などとほざいて、数年前のPCをゴミ扱いするのだ。
だが考えてみろ。お前のPCは昨日まで普通に動いていたはずだ。
YouTubeも見れたし、Excelも動いたし、Web会議だってできた。
なのに、今日から急に「古いから使えません」って、おかしくないか？
要するに、「古いPC」は技術的に使えなくなるのではなく、企業の都合で意図的に「使えないことにされている」 のだ。
Windows 11のハードウェア要件？くだらない。Linuxを入れれば動く。つまり、お前たちは「新しいPCが必要」なのではなく、「Windows 11が使えない」と錯覚させられているだけなのだ。
↓
「セキュリティのために買い替えましょう」
↓
新しいPCを買う
↓
また数年後に「古いから買い替えましょう」
本来ならば、パソコンはユーザーが自由にカスタマイズし、好きなように使い続けられるはずだ。
しかし、MicrosoftとPCメーカーは「お前のPCはもうダメ」と言い続け、お前たちは従順に買い替えを繰り返す。
その結果、「コンピュータは5年で買い替えなきゃいけない」と錯覚し、メーカーの意図通りにATMと化した消費者 になっていくのだ。
さて、ここで真実を教えよう。
Windowsが重い？遅い？買い替え？そんなものは不要だ。Linuxを入れろ。
Webブラウジング、動画再生、オフィス作業、プログラミング……お前たちがやりたいことは、Linuxで全部できる。
Windowsじゃなきゃ動かないソフト？99％の人間にとっては無関係。
「Linuxは難しい」？「使いにくい」？そんなのは20年前の話だ。
今のLinuxは、
✅ ソフトウェアは全部ストアで管理（WindowsのMicrosoft Storeより便利）
✅ UIは洗練されている（Ubuntu、Linux Mint、Zorin OSを見てこい）
だが、未だに「デスクトップLinuxは使いにくい」と言うやつがいる。
彼らはおそらく、2000年代のDebianを使った老人か、Windowsに魂を売った企業の犬 だ。
「Linuxは使いにくい」と喚いているやつがいたら、こう言ってやれ。
電気屋に行くたびに、毎回同じようなスペックのPCが同じ価格で売られていることに気づけ。
10万円のPC？お前が必要なのは2万円の中古ThinkPad だ。
ThinkPad X220、X250、T480、T490……中古で買えば、最新PCと遜色ない作業環境が手に入る。
これでお前のPCは、企業が「買い替えろ」と言うたびに「は？」と言い返せる。
お前たちは「古いPCは使えない」と思い込まされているが、それは嘘だ。
Q. Copilot+ PC エクスペリエンスは、すべての Windows 11 PC で利用できますか。
A. これらの機能には、Copilot+ PC クラスのデバイスならではの AI を多用するプロセス専用のコンピューター チップである、パワフルなニューラル プロセッシング ユニット (NPU) が必要です。
https://www.microsoft.com/ja-jp/windows/copilot-plus-pcs を参照。
ちなみに、電力効率のことを考えなければ、既存CPUとGPUだけの組み合わせだけで、Qualcomm® Snapdragon® X シリーズプロセッサーの処理性能を超えることは可能です。でも、40TOPS超のNPU搭載という要件を満たすことはできません。システム全体ではなく、具体的に40TOPS超のNPUの実装が求められているからです。つまり、既存のハードウェアがCopilot+ PCになることはありません。
https://jp.ext.hp.com/techdevice/ai/review_copilot_pc_01/ から引用。
既存のCPUとGPUの組み合わせで新機能を使えるようにしろ。
何だよNPUって。
処理性能がCPUとGPUの組み合わせを下回るなら高い方に処理を任せればいいだろ。
Windows 10から11へのアプデ要件にTPMを指定したあたりで味を占めたのか。
要件満たすため・社内政治的な理由でピンポイントで別のところ使う＋併用はあっても、
ゼロトラストセキュリティは、「信頼せず、常に検証する」という原則に基づいています。主な特徴として、常時の認証と承認、最小権限アクセス、アクセスの継続的な監視があります。以下の技術やソリューションを組み合わせることで、包括的なゼロトラストセキュリティモデルを構築できます。
1. Microsoft Entra ID（旧Azure AD）：
3. 多要素認証（MFA）：
1. 暗号化：
諸君！ThinkPadはiPhoneに対して、5つの大きな優位性を持っている！まず第一に、ThinkPadは高性能なマルチタスキングが可能である。これは、業務において必要なアプリケーションを同時に開き、作業を効率化する上で非常に重要な要素である。第二に、ThinkPadは物理キーボードとポインティングデバイスを備えているため、快適で正確な入力が可能だ。これによって、長時間の作業でもストレスを感じることなく作業を続けることができる。第三に、ThinkPadは周辺機器との互換性が高い。例えば、外部ディスプレイやプリンター、USBハブなどが利用できるため、ビジネスの現場で非常に便利だ。第四に、ThinkPadは高度なセキュリティ対策が施されている。指紋認証や顔認証、TPMセキュリティチップなどを搭載しており、貴重な情報や個人情報を守るために最適なデバイスとなっている。最後に、ThinkPadは堅牢である。落下や水濡れなどに対しても強い耐久性を持っており、ビジネスの現場で頻繁に使用されるデバイスとして、信頼性が非常に高いといえる。以上、5つの大きな理由から明らかなように、ThinkPadはiPhoneに対して圧倒的な優位性を持っているのだ！
仕組みとしては、ゼロ知識証明の一種であるDAA使うのがよいとおもう。
マイナンバーを使うと実存性は高いレベルで担保できるけどプライバシーの問題があるのでTPMくみあわせてDAAするといいと思う。
TPMからAttestation Identity Key(AIK)を生成して、マイナンバーでTPMのEndorsement Key(EK)に署名して、EKとAIKが同じTPM内部で鍵を生成したことを保証できる仕組みを使って鍵の保護となりすましを防ぎつつ、AIK → EK → マイナンバーで実存性検証をつなげる。
利用サービス毎にAIKは異なる物を利用できるので匿名性を保ちながら、実存性は担保できる。
あとはPrivacy CAを誰がサービス提供するかが問題かな。
昔Hal Finney(bitcoinの黎明期で名前が出ている人)って人がPrivacyCA作っていたけど本人は現在存命ではない
TPM組み込まれてないiOS とかでも応用すれば出来るはず。
MacはまだDevice Attestation対応してないけど、今後使える様になると思う。
Androidは知らん
あとは問題はマイナンバーの署名を検証する仕組みが必要だけど、OCSPへアクセスするたびに、金かかる。OCSPなんてリッチなの要らないからCRLでCDNかまして一日一度ぐらいでCRL更新したものばらまいてくれ。金もかからんし利活用が増えるとおもいます。
こういった需要あるんかな?作ろうかな。
追記: 上記の総務省のリンクの別紙二に小さく書いてあるし知っている。
細かい事はこちら https://www.soumu.go.jp/kojinbango_card/kojinninshou-02.html
まずは、日立のサーバーでのWindows Server 2022への対応からお聞きした。
木村： サーバーにはHA8000VとRV3000の2ラインアップがあります。HA8000VがPCサーバーで、汎用的なサーバーとして、エントリー向けや、HCI、VDIのソリューションなど、いろいろな用途で使われています。RV3000はミッションクリティカル向けです。Windows Server 2022のプレインストール対応は、HA8000Vの全機種で2022年5月を予定しています。
Windowsサーバー市場における日立の強みとして、木村氏は、サポート力を挙げる。
木村： 日立は長年に渡ってプラットフォーム製品の開発を行ってきました。作ってきたからこそ、中身がわかっている技術力があります。できることとできないことを技術者がわかっているので、障害が起きたときや問い合わせのときに、お客様に事実を真摯に伝え、重大な不具合があっても技術力で解決に向けていきます。何かあったときに問題をたらい回しにせず、技術力をコアにしてしっかり対応するサポート力が強みです。
こうした日立のDNAを結実させたサポート商品が「日立サポート360」だ。通常はサーバーのハードウェアからOS、ソフトウェアなどは、それぞれと契約し、サポートを受けることになる。日立サポート360ではこれらをワンストップで受け付け、支援することができる。
広瀬： 窓口が1つになるというのは他社でもありますが、そういう表面的な話だけではなく、複合的な力で問題解決支援にあたれるのが真の価値です。内部で、サーバーからOS、日立ミドルウェア、導入ミドルウェアなど、いろいろな製品の部門の連携がすごく濃密にされているからこそ、複合的な力で問題解決にあたれます。これが本当のワンストップの意味です。
この日立サポート360でWindows Server 2022のサポートにも対応する。日立では、長年のサポート実績により蓄積された技術力により高い自社解決率を誇るという。自社解決率が高ければ、それだけパートナーへのエスカレーションが減るわけで、短期間でのトラブル解決が期待できることになる。
日立のハイブリッドクラウドのソリューション「EverFlex from Hitachi」
木村氏は、日立のハイブリッドクラウド戦略としてEverFlex from Hitachi (以下、EverFlex)ソリューションを説明した。EverFlexは2021年10月にクラウドとのデータ連携ソリューションとして始まり、2022年2月にハイブリッドクラウドのソリューションとして強化された。
木村： お客様がオンプレミスとパブリッククラウドを使うときに、最適なシステム設計にして、コストも最適化していきます。ハイブリッドクラウドの導入には事前にアセスメントやコンサルティングを行うことが大切です。なぜなら、パブリッククラウドを導入することで負担が減るかと思われがちなのですが、ハイブリッド化されることで負担が増えることがあるからです。
EverFlexの特徴の中でも特に「クラウドライクなサービス提供」について木村氏は紹介した。
木村： ハイブリッドクラウドになると保守や運用が煩雑になります。パブリッククラウドとオンプレミスの両方を管理しなくてはならないため、システム管理において両方のノウハウが必要になります。このため保守・運用フェーズにおいて簡単化されずコスト最適化が課題となってきます。それを避けるために、共通化するニーズに応えるようにいろいろと工夫しています。
ハイブリッドクラウドソリューションEverFlex from Hitachi
まず、問い合わせをワンストップ化したり、運用管理を1つのツールで一元化したりすることで、顧客の負担を軽減する。
プラットフォームにおいては、オンプレミスからクラウド接続を可能にしてシームレスにお互いやりとりできるOSが各社ある。Windows Server 2022はまさにそれを特徴としており、同じくAzure Stack HCIも選択肢に入る。
さらに、支払い／利用形態についても、オンプレミスでも売り切りだけでなくフィー型も採用する。こうしたEverFlexの中でWindows Server 2022のユースケースを木村氏は2つ挙げた。
1つめは、運用管理の簡単化の部分で、Azure Portalからオンプレミスを管理できる機能の強化だ。
木村： オンプレミスにエージェントを入れておけば、管理者がAzure Portalだけをさわって、オンプレミスのリソースやイベントの管理も全て一元化できます。これに期待しています。
もう1つはセキュリティの強化だ。
木村： ハイブリッド化が進むと、両方の基盤をネットワークで接続することになります。従来には存在していなかった接続となるため、その部分でセキュリティの強化も進めなければなりません。そこでWindows Server 2022では、Secured-core ServerによってOSそのもののセキュリティレベルが上がっています。TPMと連動する機能によってハードからOSのレイヤーを守り、マルチレイヤーでセキュリティを強化しています。
そのほかにもクラウドライクの取り組みとして2つを木村氏は紹介した。
1つめは「サーバ予備リソース提供サービス」。サーバーを余分に設置し、支払いは電源を入れて使った月だけ発生するというサービスだ。
木村： 迅速でタイムリーにリソースを増強したいときに、クラウドなら自由に構成を変えられます。それをオンプレミスでもできるようにします。クラウドではインスタンス単位となり、ハードウェアの構成はメニューの中から選択することになりますが、オンプレミスでは構成を自由に組む事ができます。まずHCIソリューションから開始しましたが、2022年4月からはそれ以外にも拡大する予定です。
もう1つが「ハードウェア安定稼働支援サービス」。オンプレミス環境のサーバー運用管理を省力化するものだ。
木村： 旧来の保守では、ファームウェアのバージョンアップがあると、技術的にどういう影響があるかを確認して、その都度適用するかどうかを判断する必要がありました。それを提供元が判断するのがこのサービスです。お客様の機器を弊社で管理して、ファームウェアの推奨バージョンの選定や、更新作業などを一括でやります。
サブスクリプションに力を入れる
日立のこれからの注力分野について木村氏は、サブスクリプションに力を入れていくと語った。
木村： 全社的な方針で、サブスクリプションに力を入れていきます。クラウド化で初期投資をおさえるニーズと同時に、オンプレミスも求められています。そうしたお客様のニーズにアラインしていきます。
サブスクリプションやクラウドライクなサービスで管理を簡単にして顧客企業がコストを抑えることで、究極的な目的はその先のDXだと木村氏は語る。
木村： 既存のプラットフォームのコストを最適化させ、浮かせた費用を新たな投資先として、AIやEdgeを活用する新たなデジタルソリューションの領域に向けていくことを支援していきたいと考えています。
そのために木村氏は、よりハイブリッドで使いやすいようなライセンス体系をマイクロソフトに期待している。
木村： 今後ハイブリッド化が進むと、繁忙期にリソースを拡張するといったこともあります。そのときにライセンスが、オンプレミスはオンプレミスで買って、AzureはAzureで課金してと、ハイブリッドで使いづらい体系になっています。将来的にライセンス体系を統一するなど、両方の基盤で使えるような体系になることを期待しています。
また、Azure Portalからオンプレミスを管理できる機能についても、さらなる強化を木村氏は期待する。
木村： Azure Portalからは管理できる範囲に限りがあります。OSから上のリソースやイベントは監視できるのですが、ハードウェアの死活監視や電源管理などは対応していないため、JP1やその他のツールなど、複数のツールを使いこなす必要があります。それらの管理ツールが乱立してしまうと、また管理の手間が増えてしまう。こういったことをオンプレのツールか、Portal側で統一することも期待したいところです。
https://dropbox.github.io/dbx-career-framework/
SWE...無理。
QAE...お前のべしゃりわかんないってよく言われる。
SRE...色んなチームと関わる職業だから無理。誰もみないインディケーターボードにSLIをそれっぽく表示して満足するやつ。
MLE...無理。attensionとかかっこよさそうな言葉は知ってるけど、わりと最近までディシジョンツリーは知らなかったいっちょかみ野郎。
SE(Security Engineer)...Trivy使いやすいよね。関係ないけど、あの情報処理安全確保支援士で午後1落としたわ。無理。
TPM(Techinial Program Manager)...SREが運用面で全社横断的に活躍する人ならこっちはプロジェクト立ち上げで色んな人に声かけてアベンジャーズを作る司令官。無理。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 64 | 14367 | 224.5 | 69.5 |
| 01 | 60 | 5727 | 95.5 | 49 |
| 02 | 40 | 5602 | 140.1 | 46.5 |
| 03 | 32 | 8054 | 251.7 | 69 |
| 04 | 51 | 5957 | 116.8 | 69 |
| 05 | 36 | 9884 | 274.6 | 114.5 |
| 06 | 45 | 4512 | 100.3 | 68 |
| 07 | 43 | 3715 | 86.4 | 61 |
| 08 | 56 | 3782 | 67.5 | 40 |
| 09 | 88 | 8454 | 96.1 | 40 |
| 10 | 102 | 11737 | 115.1 | 48.5 |
| 11 | 124 | 10181 | 82.1 | 39.5 |
| 12 | 173 | 20122 | 116.3 | 54 |
| 13 | 155 | 14325 | 92.4 | 34 |
| 14 | 123 | 11322 | 92.0 | 41 |
| 15 | 215 | 19729 | 91.8 | 36 |
| 16 | 143 | 11559 | 80.8 | 43 |
| 17 | 138 | 13184 | 95.5 | 34 |
| 18 | 160 | 20412 | 127.6 | 50.5 |
| 19 | 118 | 11704 | 99.2 | 36.5 |
| 20 | 185 | 19207 | 103.8 | 33 |
| 21 | 156 | 19216 | 123.2 | 47.5 |
| 22 | 141 | 11556 | 82.0 | 45 |
| 23 | 147 | 9913 | 67.4 | 35 |
| 1日 | 2595 | 274221 | 105.7 | 42 |
ノンバイナリー(12), エロイプ(5), 司法権(4), ツールドフランス(5), 発火点(3), TPM(3), 非正規公務員(3), 繋がろ(5), 一票の格差(3), 148円(3), 醜形恐怖(17), ダジャレ(9), 結婚相談所(12), 共産(9), ジム(18), カースト(8), 卑屈(11), AV女優(9), チヤホヤ(8), ドヤ(9), 売春(9), YouTuber(13), 鍛え(9), 裁判官(9), 何者(10), ひろゆき(7), 劣化(9), 惨め(9), レア(7), ミュート(7), ブログ(24), 五輪(17), メンヘラ(16), 専門家(14), 接種(15), はてなー(15), 民主主義(10), 特別(20), 創作(21), 映像(12)
■ジムはマジでダメな人間が多すぎ /20210626232543(29), ■努力してゲームしないと駄目なの？ /20210626183502(28), ■ワクチン接種は時給1000円の非正規公務員で支えられている /20210626205415(24), ■ダジャレとか簡単な言葉遊びでコメントする人脳劣化してきてない？ /20210627060130(20), ■マッチングアプリ、婚活で出会ったヤバイ女たち図鑑 /20210627140517(18), ■女を売りにして同人作品の感想を買っている /20210627002506(17), ■「なんで自分が何十年とやってる専門家より知識があると思える？」 /20210627124710(15), ■マック食えてドヤるってブクマカ底辺すぎんか？ /20210626225018(13), ■はてな村民の閉塞感って「ネットでも自分が主役になれなかった」だろ /20210627165949(12), ■妻が大黒柱になっても夫は家事育児をやらない /20210627105045(11), ■ /20210627151347(10), ■五輪関係者には飲食店に来てほしくない /20210627080721(10), ■ /20210626233830(10), ■ヨーロッパはマナーがなさすぎる。教育レベル低すぎ /20210627121845(9), ■まとまった文章を書くのって難しくないか？ /20210627030229(9), ■なんでこんな人生厳しいんだろう /20210627174105(8), ■近所の野良ミケ /20210627093524(8), ■1980年（昭和55年）の港区六本木7丁目の土地の坪単価がたったの80万円で衝撃を受けてる /20210627215928(7), ■社会的地位のあるLGBTQより俺の方がよほど苦しんでるだろうが！ /20210627115351(7), ■ /20210627123101(7), ■Twitterのミュートしてるワード /20210627151917(7), ■選挙カーとボイチャ /20210626113909(7)
検証、発見、パートナーへの働きかけにまたがる複数の取り組みを通じて、Windows10からWindows11までの互換性のある設計アプローチを継続してきました。これらの取り組みに基づいて、Windows10と同じ標準であるWindows11との継続的な互換性の肯定的なシグナルがあります。変更によって互換性の問題が発生する可能性がある場合、App Assureプログラムは、商用顧客を確保するために必要なサポートを提供します。安全にアップグレードできます。 App Assureに加えて、Test Base for Microsoft 365を使用すると、パートナーはアプリを管理対象環境にオンボーディングして検証できます。
すべてのパートナーが、アプリがWindows 11で完全に機能することを検証することにより、新しいバージョンのWindowsに対する共有顧客の信頼を引き続きサポートすることをお勧めします。以下は、Windows11で行われた変更に固有の検証手順の一連のガイドラインです。 。このドキュメントは今後更新されます。
Windows 11には、新しい最小ハードウェア要件があります。Windows11を実行するには、デバイスが次の仕様を満たしている必要があります。ハードフロアに適合しないデバイスはWindows11にアップグレードできず、ソフトフロアに適合するデバイスはアップグレードが推奨されないという通知を受け取ります。
