GitHubが深刻な問題に直面しています！
MMaximilian Schwarzmüller
Computing/SoftwareBusiness NewsManagementInternet Technology
Transcript
00:00:00GitHubは今、非常に深刻で最悪な状況にあります。
00:00:04数多くの問題が発生しており、その多くはAIに関連していますが、
00:00:08皆さんが考えているような理由ではないかもしれません。
00:00:10それについては後ほど説明します。
00:00:11もちろん、これは重大な問題です。
00:00:13なぜなら、GitHubは現代の開発業務において
00:00:16屋台骨となる存在だからです。
00:00:17オープンソース開発をしていても、
00:00:20オープンソースプロジェクトをメンテナンスしていても、
00:00:22あるいは自分自身のプロジェクト、
00:00:24個人のプロジェクトやサイドプロジェクトであっても関係ありません。
00:00:26小さなビジネスや会社を経営していても、
00:00:29あるいは大企業に勤めていても同じです。
00:00:32コードアーカイブとして、あらゆる用途で使われています。
00:00:35CI/CDワークフローやコラボレーション、
00:00:38Issueを通じたプロジェクトの共同作業、
00:00:42プルリクエストなど、多岐にわたるユースケースがあります。
00:00:47ですから重要なのですが、先ほど述べたように、
00:00:49数多くの問題が山積しています。
00:00:51まずは何が起きているのかを見てから、
00:00:53その理由と、それが将来に
00:00:54何を意味するのかを考えていきましょう。
00:00:57まずは、大きなトピックから始めます。
00:00:59非常に重大で、巨大な、
00:01:02信じがたいセキュリティ脆弱性が昨日報告されました。
00:01:07ちょうど私がこれを録画している時のことです。
00:01:09github.comにおけるリモートコード実行の脆弱性です。
00:01:12これを読むだけでも、正気の沙汰とは思えません。
00:01:16発見したのはセキュリティ会社のVizで、
00:01:19悪用はされませんでした。
00:01:21発見され、報告され、そして修正されました。
00:01:25実害は出ていません。
00:01:28GitHub側によれば、
00:01:31彼らもこの報告に対する回答を公開しています。
00:01:33さて、その脆弱性がどのように
00:01:36機能したかの詳細には立ち入りません。
00:01:39記事へのリンクは下に貼っておきます。
00:01:42結局のところ、すべては git push を通じて行われました。
00:01:44フィッシング詐欺などは関係なく、
00:01:46従業員のアカウント乗っ取りでもなく、
00:01:49サプライチェーン攻撃でもありません。
00:01:51ここ数週間でそういった事例はたくさん見てきましたが、
00:01:54今回はそうしたものは一切含まれていません。
00:01:56代わりに、ただの git push でした。
00:01:58具体的には、標準的な push option 機能が使われました。
00:02:03これは git push コマンドに追加できるもので、
00:02:05push コマンドにオプションを付加するための機能です。
00:02:10このオプション機能と脆弱性、
00:02:13そしてGitHubのpush処理の方法が悪用されました。
00:02:17セキュリティ研究者たちは、あるコードを付加することに成功し、
00:02:22それがGitHubのサーバー上でそのまま実行されてしまったのです。
00:02:27繰り返しますが、詳細はこのレポートにありますが、
00:02:31結局のところ、彼らはある事実を悪用しました。
00:02:34それは、xstatヘッダーに追加のメタデータを付加できるという点です。
00:02:39このヘッダーは、push optionsフラグを使って生成されます。
00:02:44そして、そのヘッダーを通じて
00:02:49pushリクエストと共に送られるメタデータや情報は、
00:02:52最終的にGitHub側でサニタイズされていませんでした。
00:02:54彼らは最終的に、pushリクエスト、つまり
00:02:58pushコマンドの認証を行っただけでした。
00:02:59プッシュしようとしているリポジトリに対して
00:03:01権限があるかどうかはチェックしていましたが、
00:03:03そのオプションデータを取り込み、
00:03:07サニタイズせずにxstatヘッダーを構築してしまったのです。
00:03:12これにより、セキュリティ研究者たちは
00:03:15コマンドを実行することが可能になりました。それは
00:03:18プッシュ先のリポジトリ内に制限されることなく、
00:03:21GitHubのサーバー上で自由に行われ、
00:03:24他のリポジトリにもアクセスできる状態でした。
00:03:27プライベートリポジトリも含めてです。
00:03:29繰り返しますが、この脆弱性は報告・修正済みで、
00:03:33現在はもう存在しません。
00:03:35しかし、明らかにこれは巨大な問題です。
00:03:39github.comでリモートコード実行を可能にする
00:03:43脆弱性があるというのは、とんでもない事態です。
00:03:45本当に深刻なことです。
00:03:47ええ、これが一つ目の大きな問題ですが、
00:03:48もちろん問題はこれだけではありません。
00:03:514月23日、つまりほんの数日前のことですが、
00:03:56GitHub merge queuesに関連する重大な障害が発生しました。
00:04:01ご存知ない方のために説明すると、GitHub merge queuesは、
00:04:04アクティビティが非常に活発なリポジトリ向けに
00:04:07設計されたGitHubの機能です。
00:04:11プルリクエストが絶え間なく送られてくるような環境ですね。
00:04:13新しいプルリクエストを送る前に、
00:04:16前のリクエストの完了を待つ必要をなくすためのものです。
00:04:19当然、リポジトリの最新の状態、
00:04:21例えばメインブランチの最新の状態に対して
00:04:24プルリクエストを送りたいわけですが、
00:04:26新しいリクエストを開くたびに、
00:04:28前のマージを待たなくて済むようにしたいのです。
00:04:30そのために、このマージキュー機能が存在します。
00:04:34この機能のシンプルな目的は、実質的に
00:04:38中間的なマージをあらかじめ作成し、
00:04:42各プルリクエストに対して、マージ先となるブランチの
00:04:46新しい状態を作り出すことです。
00:04:49そして、プルリクエストの連鎖に
00:04:51新しいリクエストが追加されると、
00:04:53それは先行するプルリクエストと組み合わされた状態で
00:04:57メインブランチにマージされたものとして扱われます。
00:04:58これにより、あたかも先行するプルリクエストが
00:05:01既にマージされたかのように、次のリクエストを開けます。
00:05:05これによってチームはより迅速に作業できます。
00:05:08前のものが完了するのを待たずに、
00:05:10次々とプルリクエストを開けるからです。
00:05:13最終的にはどこかの時点でマージされますが、
00:05:15作業を止めることなく進められるため、
00:05:17大規模なチームなどでは特に重要になります。
00:05:19さて、この機能に関連して重要なのは、
00:05:22当然ながら正しく動作することです。
00:05:24ところが、4月23日に起きたのは、
00:05:28GitHubがこれらの異なるプルリクエストを解決する際に、
00:05:32内部的なロジックエラーが発生したということでした。
00:05:37その結果、最終的に作成されたマージにおいて、
00:05:41一部の情報が欠落してしまいました。
00:05:45これにより無効なコミットが作成され、
00:05:49Git履歴の一部が消失してしまったのです。
00:05:50実際にデータが完全に失われたわけではありませんが、
00:05:53この機能が誤動作し、
00:05:55不正確なコミットを生成してしまいました。
00:05:57これが今回のトラブルの要点、要約です。
00:06:00もちろん、これは全く容認できないことです。
00:06:03もしあなたが大企業、あるいはこの機能に依存している
00:06:06企業であれば、突然プロジェクトが壊れた状態になり、
00:06:09しかも明確な説明もないまま放置されるというのは、
00:06:13当然ながら受け入れがたい話です。
00:06:16そして、最初に疑うのは十中八九、
00:06:19マージキュー機能の内部バグなどではありません。
00:06:23「自分が何か間違えたのではないか」と思うでしょう。
00:06:26そのため、エラーの原因を探すのに多大な時間を費やし、
00:06:28ようやく「GitHub側のせいだ」と気づくわけです。
00:06:30さらに、これらすべての問題に加えて、
00:06:33GitHubが抱え続けている稼働時間の問題があります。
00:06:38公式のステータスページを見ると悪そうですが、
00:06:42まあ許容範囲に見えるかもしれません。しかし、
00:06:46少なくとも多くのシステムで「スリーナイン」の稼働率は達成できていません。
00:06:49彼らはシステムごとに稼働時間を個別に報告しています。
00:06:53しかし、「missing GitHub status page」という
00:06:55別の視点から稼働時間を追跡しているページを見ると、
00:06:57状況は少し違って見えます。
00:07:00そこでは些細なインシデントもすべて問題としてカウントし、
00:07:04最終的にダウンタイムとして計算しています。
00:07:05これを見ると、GitHubのような重要なシステムとしては
00:07:10悲惨な稼働率であり、到底受け入れられません。
00:07:14ここ数ヶ月、あるいは昨年の時点から、
00:07:18すでに稼働時間の問題は続いていました。
00:07:20また、あちこちで小さなバグも発生していましたが、
00:07:23今回のような大規模なものや、このセキュリティ脆弱性ほど
00:07:26重大なものではありませんでした。
00:07:28しかし、多くの問題があるのは事実であり、
00:07:31現時点でGitHubが信頼できないプラットフォームに
00:07:36なってしまったのは非常に残念なことです。
00:07:38冒頭で述べた通り、現代の開発における
00:07:43GitHubの役割と重要性を考えれば、
00:07:47どのような開発業務であれ、これは大惨事と言えます。
00:07:50もう一つの問題は、GitHub側からの
00:07:54コミュニケーションが、控えめに言っても不足している点です。
00:07:59あまり多くの情報は発信されてきませんでしたが、
00:08:014月28日に一つのブログ記事が共有されました。
00:08:06例のセキュリティ脆弱性が発覚する前のことです。
00:08:10そこで彼らは何が起きているのか、
00:08:14問題の原因はどこにあるのかを説明しようとしました。
00:08:16彼ら自身、これまでのコミュニケーション戦略が
00:08:19理想的ではなかったと認め、改善を約束しています。
00:08:23ここからが次の話です。
00:08:25一体、問題の原因はどこにあるのでしょうか？
00:08:28公式声明では、理由として「AI」を挙げています。
00:08:32ただし、MicrosoftのGitHubエンジニアが
00:08:36AIを使って壊れたソフトウェアやアップデートを
00:08:40リリースしている、という意味ではありません。
00:08:43そうしたことが起きている可能性もありますが、証拠はありません。
00:08:47代わりに挙げられている主な理由は、当然ながら、
00:08:51AIによってプロジェクトの数が爆発的に増え、
00:08:57膨大な量のコードが生成されているという点です。
00:09:00そして最終的に、それらすべてのプロジェクトとコードが
00:09:03GitHubにプッシュされています。
00:09:04彼らはいくつかチャートを公開していますが、
00:09:09正直あまり役に立つものではありません。
00:09:12なぜなら、Y軸の数値がないからです。
00:09:14絶対的な数値は確認できませんが、
00:09:17相対的な関係を見ることはできます。
00:09:202025年を通じて、マージされた
00:09:23プルリクエストが急増しているのがわかります。
00:09:28プッシュされたコミット、新規リポジトリ数も同様です。
00:09:32これらは、私たちがAIを使って作成し、
00:09:34結局完成させずに放置しているサイドプロジェクトの数々です。
00:09:36そして2026年に入ると、明らかにすべての指標において、
00:09:41チャートは空を突き抜けるような勢いで急上昇しています。
00:09:46ええ、これは非常に明確なトレンドです。
00:09:49このようなトラフィックの激増は、
00:09:54どんなシステムであっても負荷をかけることになります。
00:09:58GitHubにとって特に問題なのは、彼らがちょうど
00:10:01移行の真っ只中にいるという点です。
00:10:05モノリシックな構造や、独自の専用データセンター、
00:10:09専用システムから、Azureクラウドへと移行し、
00:10:13モノリシック構造ではない、より細分化された
00:10:17マイクロサービスシステムへの転換を進めています。
00:10:21これは2026年に入る前から進められていたプロセスです。
00:10:26しかし、その移行プロセスの途中で、
00:10:31この需要の急増に見舞われてしまったのです。
00:10:34つまり 移行中であっても
00:10:36現在のシステムを安定させつつ
00:10:39移行を継続しなければならないということです
00:10:40そうすることで 将来的なトラフィックの増加に
00:10:44対応できることが期待されています
00:10:46あくまで希望であり 保証はありませんが
00:10:50GitHubが対処すべき課題であることは確かです
00:10:52彼らの発表によると 2025年10月に
00:10:56キャパシティを10倍にする計画の実行を開始しました
00:11:01その頃には すでに需要の増大を
00:11:04察知していたと言えるでしょう
00:11:06それ以前から兆候はあったはずですが
00:11:0910倍の増強が必要だと決断したのは この時でした
00:11:13そして2026年2月には
00:11:1610倍ではなく30倍必要だと気づきました なぜなら
00:11:20ここでの急激な伸びがあったからです
00:11:22当然 これは移行作業と並行して
00:11:28行わなければならず 膨大なタスクとなります
00:11:33Microsoft傘下であり 小さなスタートアップではありませんが
00:11:37それでも 気が遠くなるような作業です
00:11:39これがGitHubが抱える問題の一側面であり
00:11:44私が同情を禁じ得ない点でもあります
00:11:47GitHubを叩いたり 嘲笑したりするのは簡単です
00:11:51もちろん そうすることもできるでしょう
00:11:52後ほど さらに深刻な問題についても触れますが
00:11:56これほどのトラフィック増加は どんなシステムや
00:11:59どんな企業にとっても 巨大な問題になります
00:12:03GitHubの競合他社であっても この状況下で
00:12:07よりうまく立ち回れたとは考えにくいです
00:12:09とはいえ もちろん言い訳にはなりません
00:12:10彼らはMicrosoftの一部なのですから
00:12:12この過渡期を乗り越え システムを
00:12:16新しい環境と新しいトラフィック量に
00:12:20適応させるためのリソースは 十分にあるはずです
00:12:24しかし GitHubには別の重要な問題があります
00:12:28それは 現在CEOが不在であるという点です
00:12:32前CEOのトーマス・ドムケ氏は
00:12:372025年8月に退任を発表し
00:12:41第一線を退きました
00:12:43しかし Microsoftは後任のCEOを任命しませんでした
00:12:48代わりに GitHubは「Core AI」の一部となりました
00:12:51これはMicrosoftの内部部門で 名前の通り
00:12:56AIツールの構築やプラットフォームに特化しています
00:13:01GitHubはその一部に組み込まれたのです
00:13:03つまり Microsoftから見たGitHubの使命は
00:13:07AIツールチェーンの一翼を担い
00:13:11AI革命の一部となることなのは明らかです
00:13:13Microsoftがあらゆる製品に
00:13:15Copilotを導入しようとしているのは周知の事実です
00:13:16実際 GitHub Universe 2023において
00:13:20彼らはGitHubを「AIを搭載した
00:13:24開発者プラットフォーム」へと変貌させ
00:13:28「GitHub Everywhere」を実現すると宣言しました
00:13:30これには GitHub Copilotを利用して
00:13:32Issue作成を支援する新機能なども含まれますが
00:13:36これはOSSメンテナーにとって大きな問題となっています
00:13:39同時に GitHubのあらゆる場所に
00:13:43GitHub Copilotが存在するようにもなりました
00:13:44GitHubには「Agent HQ」というものがあり
00:13:48[github.com/copilot](https://github.com/copilot) から
00:13:49GitHub Copilotと対話しながら
00:13:52直接コードの作業を進めることができます
00:13:55ローカルのIDEやエージェントツールを開く必要もありません
00:14:00他にも多くの機能が追加されています
00:14:02GitHub CopilotはGitHubの至る所にあります
00:14:05Microsoft製品の至る所に
00:14:07Copilotが存在するのと同じようにです
00:14:10これは明らかに戦略的な決定ですが
00:14:14GitHubが本来持っていた使命とは
00:14:19相反する方向に向かっているようにも見えます
00:14:23冒頭で述べたように
00:14:25GitHubは多様な開発者にとって
00:14:29あらゆるユースケースで重要な存在です
00:14:31OSSメンテナーはソースコードを公開し
00:14:36他のメンテナーやコミュニティの
00:14:39コントリビューターと協力するために利用します
00:14:41Issueはバグの発見や
00:14:45その修正作業において不可欠です
00:14:46Pull Requestは 外部の人間が
00:14:50コードベースに貢献するために重要です
00:14:52Discussion機能は 新機能や
00:14:55ライブラリの方向性を議論するのに適しています
00:15:01ここにはOSSメンテナーを支える
00:15:03多くの機能が集約されています
00:15:04少なくとも以前はそうでした
00:15:07私も 自分のコース資料のホスティングに GitHubを使っています
00:15:11ホスティングするリソースとして使う人もいます
00:15:13「awesome-go」や「awesome-rust」のようなリポジトリです
00:15:17GoやRustを使いたい時に
00:15:20便利なリソースを簡単に見つけることができます
00:15:22私自身も コースの資料を公開するために
00:15:26例えばCodexのコースなどで
00:15:29GitHubを活用しています
00:15:31つまり GitHubを一種の
00:15:33ドキュメントストレージとして利用することも可能です
00:15:36さらに CI/CDワークフローにも利用されます
00:15:40企業であれば ソースコードを管理し
00:15:43チームメンバーがPull Requestなどを通じて
00:15:46共同で開発を行うために
00:15:50GitHubを使用しているでしょう
00:15:52そして 多くの場合
00:15:54GitHubはCI/CDパイプラインの一部となり
00:15:57例えばmainブランチへのプッシュが
00:15:59パイプラインを起動させるトリガーになります
00:16:02GitHub Actionsが使われることも多いですが
00:16:05その製品自体にも独自の課題があります
00:16:08もちろん GitHub Actionsに限らず
00:16:12他のCI/CDプロバイダーを呼び出すことも可能です
00:16:16このように GitHubは伝統的な開発手法において
00:16:20非常に重要な役割を担っています
00:16:24しかし Microsoftはそれを拒否し
00:16:27単なる開発プラットフォームではなく
00:16:31「AI駆動のプラットフォーム」にすると決めました
00:16:33ここに 乖離が生じています
00:16:37開発者は GitHubのあらゆる側面に
00:16:41Copilotを求めているわけではありません
00:16:43一般のMicrosoft製品のユーザーが
00:16:46全ての製品にGitHubを求めていないのと同様ですが
00:16:48それはまた別の話です
00:16:49GitHubは 開発者にとって重要な
00:16:53コア機能をおざなりにしてきました
00:16:56OSS開発の現場を例に挙げてみましょう
00:17:00OSSプロジェクトのメンテナーは
00:17:03AIが生成したIssueやPull Requestに忙殺されています
00:17:07ここでの問題は作業の非対称性です
00:17:10AIを使ってコードやIssueを生成するのは簡単ですが
00:17:14それら全てをレビューするのは
00:17:19はるかに困難な作業だからです
00:17:24AIを利用したことがある開発者なら
00:17:26誰もが実感していることでしょう
00:17:273つ以上のAIエージェントを立ち上げて
00:17:30プロジェクトに従事させるのは容易です
00:17:32GitHubの外でも可能です
00:17:33CodexやClaude Codeなどを使い
00:17:35自分のマシン上で実行できます
00:17:36しかし 完全にAI任せにしないのであれば
00:17:39（私はそうすべきではないと考えますが）
00:17:41どこかの時点でコードをレビューしなければなりません
00:17:44それには時間がかかりますし
00:17:45少なくとも私にとっては あまり楽しい作業ではありません
00:17:48もし3つのエージェントを動かせば
00:17:513人分の出力をレビューする必要があります
00:17:54負担が大きすぎて生産性が落ちると感じたら
00:17:57エージェントの数を減らすことも
00:17:59自分で調整できます
00:18:00しかし GitHub上のOSSメンテナーの場合
00:18:03AI生成のIssueやPull Requestが押し寄せ
00:18:07逃げ場がない状態に陥ります
00:18:09それらを無視することもできますが
00:18:13それではOSSの目的を果たせません
00:18:16かといって 全てに対処しようとすれば
00:18:18あまりの多さに燃え尽きてしまいます
00:18:21個人の開発作業とは異なり
00:18:25送られてくるIssueやPull Requestの量を
00:18:29自分で制限することができないからです
00:18:30個人のプロジェクトなら
00:18:33効率が悪いと感じた時に
00:18:36エージェントの利用を控えることができますが
00:18:38パブリックリポジトリではそうはいきません
00:18:41どれだけの人がAI生成のIssueを投稿したり
00:18:45Pull Requestを送ってくるかを制御できないのです
00:18:49これはOSSメンテナーにとって重大な問題であり
00:18:53OSS界隈全体や その背後にある
00:18:56オープンソースの哲学そのものが
00:18:59AIによって窮地に立たされています
00:19:04そして GitHubはそれを助けるどころか
00:19:06正反対のことをしています
00:19:08AIが生成した粗悪な「スロップ」Issueの共有を
00:19:13積極的に助長しているのです
00:19:15メンテナーや開発者が本当に必要としているのは
00:19:18これらAI生成のコンテンツを効率的に
00:19:22処理するためのツールです
00:19:25しかし GitHubはそこに取り組んでいません
00:19:27彼らの戦略には含まれていないのでしょう
00:19:29今後 変わる可能性はあります
00:19:30先ほど触れた公式の投稿では
00:19:35主に信頼性と稼働率の問題について述べられ
00:19:39透明性を高めることなどが語られています
00:19:41また 開発者をサポートするという
00:19:44コミットメントについても言及されています
00:19:46ただ 私はあまり楽観視していません
00:19:49結局のところ Microsoftの一部であり
00:19:52独自の戦略を優先させているからです
00:19:55では 今後のGitHubはどうなるのでしょうか？
00:19:59他のプラットフォームへ移行すべき時なのでしょうか？
00:20:02XなどのSNSでは GitHubに代わるものを
00:20:05探すべきだという声も聞かれます
00:20:08実際に 移行を決めたプロジェクトもあります
00:20:12SIGはおそらく最も著名な例でしょう
00:20:15彼らは2025年11月に GitHubからCodebergへ移行しました
00:20:20しかし 現実的に考えてみましょう
00:20:22一つは 前述したように
00:20:24GitHubを襲っている膨大なトラフィックは
00:20:28どの競合他社にとっても許容しがたいものだという点です
00:20:31Microsoftのようなバックボーンがない競合なら
00:20:32なおさら深刻な事態になるでしょう
00:20:35したがって GitHubが完全に取って代わられることはありません
00:20:40個別のプロジェクト 特にOSSプロジェクトが
00:20:42理解できる理由によって GitHubを去ることは
00:20:45今後もあるでしょうが
00:20:48企業や個人の開発者の多くは
00:20:52移行することはないでしょう
00:20:54様々な問題を抱えてはいても GitHubは
00:20:57開発者のワークフローや日常業務に不可欠な
00:21:02非常に機能豊富なプラットフォームだからです
00:21:06特に企業にとって GitHubを
00:21:08他のサービスへ簡単に切り替えることは
00:21:11容易なことではありません
00:21:13信頼性の欠如が企業にとっても
00:21:15大きな問題であることに変わりはありませんが
00:21:18移行を検討し始めるまでには
00:21:23かなりの苦痛を耐え忍ぶことになるはずです
00:21:25それは間違いありません
00:21:26GitHubはあまりにも重要な存在になりすぎたのです
00:21:30Gitで管理されたコードをクラウドに置き
00:21:35共同で開発を進めるためのデファクトスタンダードです
00:21:39ですから 状況が多少悪化したとしても
00:21:43衰退することはないでしょう
00:21:45もしGitHubが何の対策も講じなければ
00:21:47いずれは人々も離れていくでしょうが
00:21:49少なくとも 稼働率や信頼性の問題については
00:21:50明らかに対策を進めています
00:21:55OSS開発におけるAIスロップの問題については
00:21:58まだ不透明な部分が多いですが
00:22:01それでも OSSメンテナーにとって
00:22:07GitHubには去りがたいほどのメリットがあります
00:22:10全員が一斉にいなくなるようなことはないでしょう
00:22:14一部のプロジェクトが離脱する可能性は
00:22:17十分に考えられますが
00:22:20GitHubの重要性を再認識してくれるかもしれません
00:22:23今後も維持されるはずです
00:22:24とはいえ この現状がMicrosoftにとって
00:22:28警鐘を鳴らすきっかけになることを願うばかりです
00:22:33GitHubに再び専任のCEOを配置し
00:22:38その重要性を再認識してくれるかもしれません
00:22:41GitHubがAIプラットフォームではなく
00:22:45あくまで開発者のためのプラットフォームであることを
00:22:49理解してほしいものです
00:22:52それがいつになるかは分かりませんが
00:22:55これがいま GitHubが置かれている状況です
00:23:00非常に深刻な事態です
00:23:03当面はこの厳しい状況が続くでしょうが
00:23:06年内には信頼性だけでも
00:23:11改善されることを期待しましょう
00:23:13今後の動向を見守りたいと思います