はじめに Note この記事は、/mobile-vendor-market-share/ の更新版です。 いま現在の日本・世界のスマホメーカー別シェアを知りたい方は、この 2026 年版を読めば大丈夫です。 一方で、2022 年当時のメーカー構成や当時の見え方をそのまま確認したい場合は、旧版記事も参考になります。 こんな疑問にお答えします。 2026年の日本で、いちばん使われている Android メーカーはどこか 2022年版から見て、どのメーカーが伸びて、どのメーカーが消えたのか 世界全体では、Samsung と中国メーカーのバランスはどう変わったのか この記事では、StatCounter Global Stats のモバイルメーカー（Device Vendor）データをもとに、日本と世界のスマホメーカー別シェアを比較します。 2026年6月に確認した時点で、StatCounter 上で取得できる最新月は 2026年5月 でした。 なお、2022 年版からの変化が分かるように、前回記事と比較しながら読める構成にしています。 どのAndroidスマホメーカーが人気？日本と世界でシェア率を比較調査（2022年版） 3秒でわかる要点 日本のいちばん大きい変化 ...

AIエージェントに開発を任せる仕組みを「どこまで自前で持つか」で悩んでいる人向けの記録です。結論から言うと、私はローカルForgejoでの完全自前運用を一度組み上げ、そして捨てました。捨てて初めて分かった「管理を手放す価値」と、その先で出会ったスマホ運用のパラダイムシフトまでを、時系列で残します。 これは「やってみてうまくいった成功談」ではなく、「作り込んで撤退した正直な記録」です。3日かけて組んだものを3日で捨てたので、その判断に至るまでの過程と、そこで得た教訓を共有します。 きっかけは、以前作った agent runner だった そもそもの出発点は、以前作った GitHub IssueからCodexを動かすagent runner でした。 GitHub Issueをキューにして、VPS上のrunnerがそれを定期的に拾い、Codex CLIを非対話で実行してPRまで作る。ターミナルに張り付かなくても、スマホからIssueを投げれば作業が進む。ここまでは確かに動いていて、私の開発体験は一度大きく変わりました。 ただ、AIエージェントを使い込むほど、人は欲が出てきます。「この仕組み、もっと自分の手元に寄せられないか」と。そこから今回の迷走が始まりました。 GitHubのIssueが使いづらくて、自分で作り始めた そもそもの発端は、もっと素朴な不満でした。GitHubのIssueが、どうにも使いづらかったのです。 動作がなんとなくもっさりするし、リポジトリが増えてくると「これはどのリポジトリのIssueだったか」が分かりにくい。実際、別のリポジトリにIssueを書き間違える、というミスが何度も起きていました。 それで、こう思ったのです。「Issueくらいなら、自分で作ってローカルサーバーに立てておけばいいのでは」と。さっそく、AIエージェントの力を借りて、Issue管理の仕組みをさくっと自作しました。 ところが、作っているうちにスコープがどんどん膨らんでいきます。Issueがあるなら、プルリクエストも要るのではないか。PRがあるなら、差分を確認する仕組みも要るのではないか。AIエージェントがIssueを読み込むところまではいいとして、その後のPRやレビューのやり取りは、いったいどう作ればいいのか。 考えているうちに、はたと気づきました。これは結局、GitHubそのものを作ろうとしているのではないか、と。 であれば、答えは単純です。同じものがOSSにあるなら、それを使えばいい。そこでOSSの Forgejo を採用しました。ForgejoはGiteaから派生した、セルフホスト前提のGitフォージです。GitHubに近いIssue・PR・Webhookの機能が一通りそろっています。 根っこには、外部サービスへの依存を切りたい、全部を手元に置きたい、という気持ちもありました。実行時間の枠や無料プランの制約、コードやIssueを外部に預けることへのうっすらとした抵抗。そして正直に言えば、「この仕組みを一から自分で組んでみたい」という技術的な好奇心も、大きな燃料だったと思います。 そこでローカルにサーバーを立て、Forgejoをインストールしました。ただ、立てて動かすまでにも、地味な手間が少しずつ積み重なります。APIトークンや権限まわりの設定、サーバーとして動かし続けるための構築と運用。意外なことにWebhook連携そのものは素直に動いたのですが、「GitHubなら最初から用意されていたもの」を一つずつ自分で揃え直している感覚は、この時点ですでにありました。 「これでGit基盤も含めて、開発のループが全部自分の管理下に入る」——そう思っていました。 ClaudeとCodexで「3往復の自動レビュー」を組んだ Forgejoを土台に、私は前回のrunnerをさらに進化させた「エージェントランナーv2」を組みました。 流れはこうです。 ForgejoにIssueを書く そのタイミングでWebhookが発火し、処理が起動する Claude CodeがIssueを読み取る そのままClaude Codeが実装まで進める その実装を内部でCodexにレビューさせる このレビューのやり取りを最大3回まで自動で往復させる 完成したらIssue/PRにコメントで結果を返す ポイントは、AI同士が互いをレビューし合う閉ループを自動で回す構造にしたことです。Claudeが実装し、Codexがレビューし、また直す。前回の記事で AIエージェント自身がテストを実行して直す閉ループ の話を書きましたが、それを「実装者AI」と「レビュアーAI」の二者間にまで広げた形になります。 Issue → PR → レビュー往復 → コメントに記録を残しつつ手元に戻る。図にすると一本の気持ちのいいパイプラインで、組んでいる間はかなり楽しかったです。 つまずいたのは「どのサーバーに置くか」だった ところが、組み上げた直後から現実的な問題が頭をもたげてきました。「これ、結局どのサーバーで動かし続けるのか」という問題です。 最初はローカルのマシンに置きました。しかしローカルに置いたままでは、外出先など別のネットワークからは叩けません。そこで VPN でつなぐことを考え、Tailscale を試しました。手元のマシン同士を VPN 網で直接つないでしまえば、外からでも安全にアクセスできます。 ただ、普段使いの Mac のバックグラウンドで VPN クライアントが常駐し続けるのが、どうも好きになれませんでした。ならばと、VPS 側に Tailscale を入れて、運用一式を VPN ネットワークの中に閉じ込めてしまえば安全ではないか——と考えて構成してみました。 しかし実際にやってみると、これがなかなか雑で、手間のかかる構成でした。管理する箇所もトラブルの種も、明らかに増えていきそうです。結局、この VPN 構成は廃止しました。 ...

Cyberduck や scp、sftp で Linux サーバーへファイルをアップロードするとき、転送が終わるまで対象ディレクトリには何も見えないと思っていた。 でも実際には、アップロード開始直後から転送先にファイルが作られ、そこへ少しずつデータが書き込まれていくことがある。大きなファイルを送ると、サーバー側で ls -lh したときにサイズが増えていく様子が見える。 これ自体は普通の挙動だが、知らないと少し危ない。 たとえば、アップロード先を別のバッチ処理やファイル監視デーモンが見ている場合、まだ途中のファイルを「完成したファイル」として読み込んでしまう可能性がある。jar、画像、CSV、バックアップファイルなど、読み込み側がファイル名だけで判断していると起きやすい。 WinSCP（Windows 向けの SFTP/SCP クライアント）はデフォルトでこの問題を回避している。転送中は内部で一時ファイル名を使い、完了後に正式名へリネームする仕組みが組み込まれているためだ。一方、macOS の Cyberduck は有料課金していてもこの挙動にはなっておらず、普通にアップロードすると転送中から正式名でファイルが見える。 アップロード中のファイルは見える scp や sftp の put は、基本的には転送先のファイルを開いて、そこへデータを書いていく操作だ。 そのため、転送中は次の状態になりうる。 転送完了前のファイルが、不完全なサイズで存在する 転送に失敗すると、中途半端なファイルとして残ることがある 監視処理やバッチ処理が、そのファイルを先に読んでしまうことがある 確認してみる 挙動は、大きめのダミーファイルを送るとすぐ確認できる。 まず手元の Mac などで、500MB のファイルを作る。 dd if=/dev/urandom of=testfile.bin bs=1M count=500 サーバー側では、転送先ディレクトリを監視しておく。 watch -n 0.5 'ls -lh /path/to/target/' 別ターミナルから scp でアップロードする。 scp testfile.bin user@hostname:/path/to/target/ サーバー側の watch で testfile.bin が現れ、サイズが少しずつ増えていけば、転送中のファイルが見えている。 確認が終わったら、ダミーファイルを削除する。 # 手元 rm testfile.bin # サーバー側 rm /path/to/target/testfile.bin supコマンドで安全に転送する 対策の考え方はシンプルで、最初から正式名で置かないことだ。一時ファイル名でアップロードし、完了後にアトミックな mv で正式名に切り替える。 ...

Claude Code を使い始めてしばらく経ち、Issue ベースで作業を指示するフローは固まってきた。そこで気になっていた Skill という仕組みを調べた。「繰り返し依頼に便利」とは聞いていたが、実際に何をするもので、Issue や CLAUDE.md と何が違うのかを整理しておきたかった。 Skill とは何か Skill は .claude/skills/<skill-name>/SKILL.md の形で置く Markdown ベースの追加手順だ。ファイルには YAML front matter の description と、実行時の指示を書く。 呼び出され方は2通りある。 Claude Code が description を見て関連すると判断したとき、自動で読み込む ユーザーが /skill-name の形で明示的に呼び出す Skill ディレクトリにはテンプレートや参考資料、スクリプトも同梱できる。プロジェクト単位・個人環境単位のどちらにも置ける。 公式ドキュメントでは、同じ指示やチェックリストを何度もチャットに貼っている場合や、CLAUDE.md の一部が事実ではなく手順書になってきた場合に Skill 化するとされている。本文は使われるときだけ読み込まれるため、長い参照資料を常時コンテキストに入れずに済む点がメリットだ。 Commands との関係 以前は .claude/commands/deploy.md という単一ファイル方式のカスタムコマンドがあった。現在は Skills に統合されており、どちらも /deploy のようなスラッシュコマンドとして動く。 方式 パス 特徴 Commands（旧） .claude/commands/deploy.md 単一ファイル、シンプル Skills（現在推奨） .claude/skills/deploy/SKILL.md ディレクトリ構造、自動呼び出し対応 既存の .claude/commands/ は引き続き動作するが、新しく作るなら .claude/skills/ が推奨だ。 Skill の書き方 SKILL.md の構造 SKILL.md は2つのパートで構成される。 --- name: gen-test description: テストを生成する disable-model-invocation: true --- 以下のファイルのテストを生成する: $ARGUMENTS 1. ソースファイルを読む 2. テスト対象の関数を特定する 3. プロジェクトの規約に沿ったテストを書く --- で囲まれた上部が frontmatter で、Claude に「この Skill をいつ・どう使うか」を伝える設定欄だ。YAML 形式で書く。--- 以降が実際の指示内容になる。 ...

Claude Code に作業を任せて別のことをしていると、いつの間にか完了していたり、許可プロンプトで止まっていたりすることがある。 「通知が来れば気づけるのに」と思って設定を試してみた。結果としては動くのだが、期待していたほどスムーズではなかった。以下は試行錯誤の記録として参考にしてほしい。 組み込み設定とその限界 Claude Code には preferredNotifChannel という組み込みの通知設定がある。 { "preferredNotifChannel": "auto", "inputNeededNotifEnabled": true } ただしこれは iTerm2 の通知機能を経由するため、セッション名や生のエスケープシーケンスがそのまま通知に表示されることがある。複数プロジェクトを同時に動かしていると通知が混在して読みにくくなる。 hooks で osascript を使う 組み込み設定に限界を感じたので、~/.claude/settings.json の hooks を使って macOS ネイティブの通知を直接出す方法も試してみた。 { "hooks": { "Stop": [{ "hooks": [{ "type": "command", "command": "osascript -e \"display notification \\\"作業が完了しました\\\" with title \\\"Claude Code [$(basename $PWD)]\\\" sound name \\\"Glass\\\"\"" }] }], "Notification": [{ "hooks": [{ "type": "command", "command": "osascript -e \"display notification \\\"入力が必要です\\\" with title \\\"Claude Code [$(basename $PWD)]\\\" sound name \\\"Ping\\\"\"" }] }] } } Stop は Claude が作業を終えたとき、Notification は許可プロンプトや質問で入力待ちになったときに発火する。 ...

AIエージェントを使うようになってから、古くからある make コマンドの便利さを改めて感じている。 make は C 言語のビルドで使う古い道具、という印象が強かった。自分も昔から知っていたが、仕組みをきちんと理解して使っていたわけではない。 ところが、Claude Code や Codex のような CLI 型 AI エージェントを相棒に開発すると、make はかなり相性がいい。 理由は単純で、プロジェクトでよく使う操作を make test、make build-release、make device-debug のような短いコマンドにまとめられるからだ。人間と AI エージェントが同じコマンドを見て、同じように実行できる。 特に iOS アプリ開発では効果が大きい。make device-debug でビルド、実機インストール、起動までできるようにしておくと、Xcode を開かずにターミナルだけで開発を進められる場面が増える。Xcode は他の IDE と操作感がかなり違い、毎回開くのが負担に感じることもある。Xcode への依存を半分でも減らせると思うと、iOS アプリ開発の心理的なハードルも下がる。左半分のターミナルで Claude Code などの CLI AI と対話し、右半分や別タブで make を叩く。あるいは AI エージェント自身に make test を実行してもらう。 GitHub Issue とターミナルがあれば、基本的な開発作業がかなり済んでしまう。 makeは何をする道具なのか make は、Makefile に書かれたルールを読んで、必要なコマンドを実行する道具である。 GNU Make のマニュアル では、make は大きなプログラムのどの部分を再コンパイルする必要があるかを自動判定し、そのためのコマンドを実行するユーティリティとして説明されている。 もともとの発想は、ファイル同士の依存関係を見て、変更があった部分だけを更新することだ。 たとえば C の世界なら、main.c から main.o を作り、複数の .o をリンクして実行ファイルを作る。ヘッダーファイルが変わったら、それに依存するソースを再コンパイルする。こういう関係を毎回人間が覚えて実行するのは面倒だし、間違いやすい。 ...

ここ最近、AIエージェントをかなり集中的に触っていた。 Codex の $100 プランを契約し、20日ほどがっつり使ってみた。 結論から言うと、来月からは $20 プランへ戻す予定である。 理由は単純で、$100 プランの容量を使いこなすほど、自分の指示が追いつかなかったからだ。 Codex が物足りなかったわけではない。 むしろ十分すぎた。 5日のコンテキスト上限を使いこなすほどの指示を、自分が出せなかった。 つまり、自分の処理能力が先に限界へ来た。 CLI型AIエージェントのすごさは「フィードバックループ」にある Codex に限らず、この手の CLI 型AIエージェントを導入してすごいと思ったのは、ローカルプロジェクトを理解してくれることだった。 これまで Web ブラウザ版の ChatGPT を使ってコード修正を相談する場合、修正したいファイルを毎回アップロードしたり、コードを貼り付けたりする必要があった。 しかし CLI 型AIエージェントでは、ローカルのプロジェクトをそのまま見てもらえる。 そのため、プロジェクト全体をまるで把握しているかのように、かなり的を射たコーディングをしてくれる。 ただ、改めて考えると、すごさはそれだけではない。 もっと大きいのは、AIエージェント自身がテストコードを実行できることだと思う。 AIがコードを改修する。 そのコードに対してテストを実行する。 テストが失敗したら、エラー内容を読んで、もう一度コードを直す。 そしてまたテストを実行する。 これは、単なるコード生成ではない。 入力に対して出力を返すだけではなく、その出力結果を観測し、フィードバックして、次の修正に反映する流れである。 制御工学っぽく言えば、開ループではなく、閉ループになった感じがある。 これまでのAIチャットは、どちらかといえば「コードを提案して終わり」だった。 しかし CLI 型AIエージェントでは、生成したコードを自分で実行し、結果を見て、自分で修正する。 このフィードバックループが入ったことで、AIによるコーディングはかなり実用的になった。 人間に例えれば当たり前の話だが、たったこれだけで、精度はぐんと上がった感がある。 （このことは、今後 AI をうまく使いこなすための大きなヒントになるかもしれない） もちろん、すべてが完璧になるわけではない。 テストが通っても、仕様として正しいとは限らない。 こちらの気持ちや意図まで理解するには程遠い場面も多々あり、最後は人間による判断が必要になる。 それでも、テスト結果という強いフィードバック信号をAI自身が扱えるようになったことは、かなり大きな変化だと思う。 Claude も契約してみた 一方で、Claude の $20 プランも契約してみた。 CLI AI エージェントは Claude が先駆者だと思うが、Codex を先に体験してしまったので、Claude を使うことに今更感があり少し足踏みしていた。 しかし、実際に使ってみると Codex との違いを比較できて、かなり面白かった。 ただし、契約時にはクレジットカード決済で少し苦労した。 なかなか決済が通らず、最終的には VISA の楽天カードについてサポートへ連絡し、ストップされていた件を説明して解除してもらうことで、ようやく決済できた。 ...

この記事で伝えたいこと Codex などの AI コーディングエージェントを使うと、コードを書く時間そのものは短くなる。一方で、実際に使い込むほど「エージェントへ指示を出す」「結果を確認する」「失敗したら再実行する」「別の作業をもう一つ投げる」といった運用に時間を取られるようになった。 気がつくと PC の前に張り付き、ターミナルを 4 窓から 8 窓くらい開き、どの作業がどこまで進んでいるのかを追い続けていた。これはこれで便利ではあるが、開発体験としてはまだ人間がかなり忙しい。 そこで、GitHub Issue をキューとして使い、VPS 上の agent runner が Codex CLI を非対話で動かす仕組みを作った。この記事ではプログラムの細部ではなく、なぜ作ったのか、GitHub Actions と何が違うのか、どんな構成で動かしているのか、そして何が変わったのかを整理する。 「agent runner」 はあくまで自作のプロダクト名であり、前回の記事 さくらのサーバーでCodexをcronで動かしてブログ記事を自動リライトさせる をさらに進化させた形である。 想定読者 この記事は、すでに AI コーディングエージェントを使っている開発者に向けて書いている。 特に次のような人を想定する。 Codex CLI や Claude Code などのエージェントを日常的に使っている ターミナルを複数開いて並行作業している GitHub Issue や PR を開発の入口として使っている CI/CD とは別に、AI エージェントへの作業依頼をうまく管理したい 導入: AI 駆動開発は便利だが、人間が忙しい AI コーディングエージェントを使うと、実装、調査、テスト修正、ドキュメント作成などをかなり任せられる。 ただし、使えば使うほど別の課題が出てくる。 ターミナルをいくつも開いて、複数のエージェント作業を見張る必要がある どの作業に何を指示したか分からなくなりやすい 失敗した作業を再投入するたびに、文脈を思い出して指示し直す必要がある PC の前にいないと、次の指示を出しにくい エージェントは作業を進めてくれる。しかし、作業を投げる入口がターミナルに閉じていると、人間は結局ターミナルの前から離れにくい。 この状態を変えたかった。 なぜ Codex GitHub Action ではないのか 最初に考える選択肢は GitHub Actions だと思う。GitHub のイベントをトリガーにして処理を走らせるなら、Actions は自然な選択肢だ。 ...

ブログ記事の簡単なリライト作業を、手元のMacではなくサーバー側でも動かすようにしてみました。 やりたいことは、サーバーにブログ用リポジトリを clone して、その中で Codex CLI に記事リライト系の作業を任せ、さらにコミット・push・PR作成までを自動化することです。 実際には gh の権限、privateリポジトリのclone、Codexのログイン、sandbox など、細かいところでつまずいたことがいくつかありました。それらを中心に、備忘録として残しておきます。 やりたかったこと まずはサーバーにSSHでログインし、GitHubリポジトリを用意します。 仮に、clone先は以下とします。 /home/appuser/repos/private-blog ここにブログのprivateリポジトリをcloneして、記事リライト用のバッチ処理から Codex CLI を呼び出します。最終的には、このバッチ処理をcronで定期実行する想定です。 当然、git / gh / codex がシェルで使えるように、サーバー側へ各コマンドをインストールしておく必要があります。 本番サーバーでやるのが怖い場合は、もう1台サーバーを用意するのも現実的です。さくらVPSなら比較的安いですし、私も本格運用するなら別サーバーを用意する予定です。 もちろん、ラズパイなどを使って自鯖で処理させるのも十分ありだと思います。 サーバー側でCodexに作業させるので、本番公開ディレクトリとは必ず分けておきます。 /home/appuser/public-site # 公開用 /home/appuser/repos/private-blog # 作業用clone また、私の場合は、リポジトリのmainブランチも直接編集させず、worktreeを使った別ブランチで作業させるようにしています。 全体の関係は、次のようなイメージです。 今のところ、PRのレビューからbuild / deploy作業までは、人間が担当するようにしています。 そのためローカルMacの出番は、最初の初期設定とPR確認が中心です。そこまで整えば、毎回SSHでサーバーに入って手作業する必要はかなり減ります。 なぜGitHub Actionsではなくサーバー上のcloneで回したか ところで、この手の自動化をChatGPTへ相談すると、かなりの確率で GitHub Actions 案が出てきます。 MicrosoftはGitHubを買収済みで、OpenAIにも大きく投資しています。 Microsoft → GitHubを買収済み Microsoft → OpenAIへ大規模投資 だからActionsが推されるのでは、と邪推したくなるくらい毎回出てきます。もちろん半分冗談です。実際には、定期実行やPR作成までGitHub側で完結できるので、CI/CDの定番案として出てくるのだと思います。以前、VPSへのデプロイでは GitHub CI/CD で VPS へ自動デプロイするまで にまとめたように、Actionsの便利さも確認しています。 それでも今回は、サーバー上のcloneで動かす方を選びました。 理由は主に3つです。 1つ目は、すでにサーバー上で日次処理を動かす前提があったことです。記事リライトはサイト運用のローカルな作業に近く、実行ログや失敗時のworktreeをサーバー上に残せる方が追いやすいと考えました。 2つ目は、秘密情報を増やしたくなかったことです。GitHub Actionsに渡すsecretを増やすより、サーバー側のenvファイルに閉じた方が、今回の小さな運用では見通しがよくなります。 3つ目は、OpenAI API key を新しく使わずに進めたかったことです。Codex CLIはChatGPTログインでも使えるため、今回の確認ではAPI keyを新規発行せず、手元で使っているアカウントのログインで試しました。もちろん、公式にはAPI key認証もあり、CIや完全自動化ではAPI keyの方が向く場面もあります。ここでは「今回の運用では使わなかった」という整理です。 ...

RSSはもう死んだものだと思っていた。 でも、そうではなかった。 海外の主要ニュースサイトから見出しを集めて、CLIでニューストピックを表示するアプリケーションを作ろうとしたことがきっかけだった。AIによる成果物を動かしてみて、裏側ではスクレイピングをしているのだろうと思っていた。ところが、実際にはRSSフィードから更新情報を取っていた。 つまり、RSSは死んでいなかった。 死んでいたように見えたのは、RSSそのものではなく、普通の人がRSSを意識して使う入口だったのだと思う。 Google Readerが終わっただけだった RSSが終わったように感じられた象徴的な出来事は、Google Readerの終了だった。 Googleは2013年3月13日の公式ブログ記事「A second spring of cleaning 」で、Google Readerを2013年7月1日に終了すると案内している。公式ブログでは、熱心なユーザーはいたものの、利用が減少していたことが理由として説明されていた。 Google Readerを使っていたわけではないが、そんな私でも記憶しているほど当時は驚きのニュースだった。 RSSを読むための代表的なツールの一つが終了となったことで、一般ユーザーの視界からRSSは急速に消えていったように見える。その後はSNSのタイムライン、ニュースアプリ、レコメンド、今ならAIによる要約やおすすめが、情報を受け取る入口になった。 だから、Google Readerが終わったことと、RSSという仕組みが終わったことは別の話である。 きっかけは海外ニュースをCLIで眺めるツールだった 今回作ろうとしたのは、海外ニュースの見出しをCLIでざっと確認するための小さなツールだった。 リポジトリはこちら。 aragig/shell-toolbox の news-topics 実行すると、複数の海外ニュースサイトから見出しを集めて、ターミナルに一覧表示してくれる。 以下は news コマンドを実行した出力イメージだ。 海外ニュースの見出しをnewsコマンドで表示しているターミナル画面 % news News Topics 12 items | balanced by source cap (2/source) 01. 原油価格が2022年以来の最高値に急騰 [BBC] 2026-04-30 06:55 UTC EN Oil jumps to highest price since 2022 URL [https://www.bbc.com/...](https://www.bbc.com/) 02. ジェット燃料価格の高騰が山火事の消火費用を押し上げている [NPR] 2026-04-30 07:00 UTC EN How rising jet fuel prices are driving up the cost of fighting wildfires URL [https://www.npr.org/...](https://www.npr.org/) BBC / Reuters / NPR / DW / France 24 / Al Jazeera など、複数のニュースサイトから取得する。ソースごとの上限とラウンドロビンでひとつのサイトに偏らないように表示している。 ...