AI 10倍生産性エンジニア症候群から抜け出すのに役立ったこと
(colton.dev)- AIがエンジニアの生産性を10〜100倍高めるという主張は現実的ではない
- 実際にAIコーディングツールを深く使ってみると、効率向上は限定的で、反復的で単純な作業でのみ一時的な生産性の急増が起きる
- ソフトウェア開発のボトルネック（コードレビュー、協業、企画など） はAIでは克服できず、業務全体が10倍改善することはない
- 10倍エンジニア神話は、数値の歪曲、業界の利害関係者、あるいは組織内の不安をあおることなど、さまざまな動機から生まれている
- 自分なりの開発スタイルと楽しさを保つことが、長期的にはより良い結果と健全な組織文化を生む
AI 10倍エンジニア神話への懐疑
生産性不安とAIツール実践利用の経験
- LinkedIn、Twitter などで AIがエンジニアの生産性を10〜100倍に高める という言説が広がり、多くの開発者が 取り残されるかもしれないという不安 を感じている
- 筆者もAIコード生成エージェント（Claude Code, Cursor, Roo Code, Zed など）をさまざまに実務投入してみたが、単純な反復作業では便利だった一方で、複雑な実務においては 根本的な変革はなかった
- JavaScript（特に React）では反復的なコード（boilerplate）を素早く書ける
- しかし独自のコードベース標準や特殊なライブラリには、AIがうまく追従できない
- Terraform のような言語では AI が不慣れで性能が落ちる
- ハルシネーション（hallucination）現象により、実在しないライブラリを生成して セキュリティ脆弱性 まで引き起こしかねない
- AIの文脈理解能力はまだ限定的である。実際のコードベースが複雑になるほど、反復的なプロンプト、エラー、時間の浪費が発生する
- 結果として、筆者は小規模なスクリプトや非中核業務にAIを活用し、複雑または重要な作業は依然として自分で処理している
ソフトウェア開発の生産性を数値化する問題
- AIで生産性が 10〜100倍 高まるという主張は現実とかけ離れた数値である
- 10x、100x の生産性とは単にコード行数のことではなく、3か月かかる仕事（開発全体、コードレビュー、QA など）が1.5週間で終わることを意味する
- ソフトウェア開発には、企画、ストーリーポイント見積もり、バグ修正、コードレビュー、デプロイ待ち、テスト、QA など多様なボトルネックがある
- 目標を達成するには、それぞれの全工程が 同じ比率で10倍速くならなければならない
- 実際にはコーディングそのものに費やす時間は少なく、多くの時間は 理解、設計、検討、コミュニケーション に使われる
- 現実的に見て、コードレビュー、協業、コミュニケーション、QA などはAIでは短縮できない
- 実際のエンジニアリング業務の ボトルネックは人、プロセス、コミュニケーションにある
- LLM（大規模言語モデル）はキーボード入力の時間を減らしてくれるが、コード品質・テスト・レビューの時間は依然として必要である
- AIがコード作成速度を一時的に高めることはあっても、エラー率の増加、コード標準の不備、再プロンプトなどにより、全体の生産性向上に決定的な影響は与えない
- 10倍の生産性は現実的には 不可能に近い目標 である
10倍エンジニアの実像と限界
- 「10倍エンジニア」 の存在については、一時的・限定的 にはあり得ると考えている
- 最大の理由は、不要な仕事を未然に防ぐ能力（企画段階で不要な開発を防ぐ、開発体験を改善する、ドキュメント化するなど）の蓄積によって生まれるためである
- ただし、すべてのエンジニアが毎回こうした状況に出会うわけではない
- 卓越したエンジニア は不要な仕事を防いだり、システム改善を通じて組織全体の効率を高めたりできるが、実質的に 継続して10倍の成果を出す事例はほとんどない
- AIコーディングツールは 不要な仕事の予防にはあまり貢献しない
- むしろAIの提案によって 過剰実装 になったり、誤ったアーキテクチャを提案されたりすることがある
- コーディングが速いことが、常に優れたエンジニアを意味するわけではない
10x AI神話の背景と動機
大半の 「10倍生産性」 という主張は、次のような要因に由来している
- 測定誤差を起こす善意のエンジニア
- AIツールによって短時間に 爆発的な効率体験（例: ESLint のカスタムルール自動作成）を得られることがある
- しかしこうした作業が繰り返されると、結局 生産性の差は急速に縮まる
- 技術的な新奇性や新しい環境への適応などが、初期には過大な効率の錯覚を生み得る
- インセンティブと利害関係者
- AIスタートアップの創業者や投資家などは、事業的成功のために誇張された数値をしばしば引用する
- エンジニアや経営陣も、組織内の期待に応えるために 誇張された生産性を口にすることがある
- 悪意ある目的
- 一部の経営陣は、エンジニアの不安をあおり、転職や賃上げ要求など組織内の動揺を防ごうとする意図で誇張された主張を広める
- AIによって誰でも簡単に置き換えられるという恐怖は、周期的に繰り返されている（過去のコーディングブートキャンプ論争と類似）
現実のオープンソース・実務プロジェクトにおけるAIの成果
- AIの生産性向上に関する実例の多くでは、書き手と、生産性が向上したとされるエンジニアとの間に距離 がある。
- 実際のエンジニアが自ら証明したAIツール活用事例は、誇張のない現実的な姿 を示している
- オープンソースプロジェクトでのAI活用結果は、多くの場合 期待以下、あるいは失敗事例 として現れることもある
- 公開デモや実際のエンジニア事例 ではAIが時に魔法のように見えることもあるが、その大半は既存の 「テキスト生成器」 と大きくは変わらない
「生産性」より重要な価値 - 自分らしい開発スタイルを保つこと
- AIを使えば、時にはより速くコードを書けるが、筆者は依然として コーディングそのものの楽しさ をより重視している
- AIコーディングを好まない、または楽しくないなら、生産性の一部を手放しても構わない
- ある程度の非効率を受け入れてでも、自分に合ったやり方 で働くことが長期的には健全で良い結果を生む
- 楽しく働くと、より良い 問題解決能力、設計、同僚との協業 が可能になる
- 楽しさと没入感が長期的な生産性とコード品質により重要 であり、無理に生産性だけを追うとバーンアウトのリスクが高まる
- 逆に、AIコーディングが本当に楽しく役立つなら積極的に活用 してもよい
健全な組織文化のための助言
- AIツール導入時に、すべてのエンジニアに非現実的な期待と不安を与えることは、組織の生産性に有害 である
- 生産性最大化への執着は、品質低下、コードベース悪化、長期的損失 につながる
- エンジニアに十分な自律性と信頼を与え、AI活用は各自に合った形で選べるようにする ことが望ましい
- 組織としてはAI活用の機会を提供しつつ、自律性を保証する雰囲気 が重要である
- LLM や AI コーディングの革新が本当に10倍の生産性をもたらすなら、開発者は自然に自分で見つけるようになる
結論
- AIによる10倍エンジニア革命は神話 に近く、実際に見落としている秘密のレシピはない
- 自分の実力とやり方への 信頼が最も重要 である
- SNS（特に LinkedIn、Twitter）は誇張された神話を拡散するので、無視しても差し支えない
10件のコメント
10xを本当に10倍だと解釈する人がいたんですか。もちろんマーケティングや自己PR向けの誇張表現だと思っていたので、真に受けている人がいて戸惑いますね
10xとまではいかなくても、Nxに対して本気で確信を持っている組織はかなりあります。人件費をAIコストに置き換えて、それ以上の成果を期待するという……
それが根拠のない思い込みでもないのは、PMが簡単なPoCを試してみたいとか、反復業務ツールのようなものはあっという間にできてしまうからです。
だから開発者の中にこれを信じる人がいるのか……についても、置かれた状況次第では十分に不安を感じてもおかしくないくらい、業界の空気はそういう方向に満ちていると思います。
非開発職種や組織長とのコミュニケーションのためにも、こうした真剣な議論は必要だと思います。
もちろん、生産性の向上に役立つものを否定しているわけではありません。（現時点のAIの水準では）10xというのは当然あり得ないと思っていて、きちんと「10倍にはならない」と述べているのが元の投稿の内容なので、それがとても不思議に感じられて書いたコメントなのですが、表現は少しよくなかったかもしれません。
AIの生産性がマーケティング／自己PR向けの誇張表現だとおっしゃるように、その文章にも多少の誇張が含まれていると思います。
だからこそ、10xを本当に10倍という意味に解釈する人がいたのか、という話は、何か揚げ足取りをしているような印象があり、それで反感を買ったのではないかと思います。
元文を読まずに返信されたようですね。元文のどこにも深刻ぶったところはなかったのですが……
筆者の方が開発された、YouTubeのバイラルアイデアを探す DataTube.tv の Viewtrap 比で「数十倍」の利用量というのも、当然マーケティング／自己PR用の誇張表現ですよね？
オンラインだからなのか、もともとそういう方なのか、批判的な視点で書かれたコメントがほとんどでしたが、
もう少し開かれた視点で見ていただければと思います。
AIの大げさな持ち上げがあれば、その逆もあると思うので本文にはあまり思うところはありませんが…
このコメントは、過去の投稿まで探してコメントし直されるのが怖いですね、今日入会されたばかりなのに
コメントを拝見して自分の履歴を見返してみても、別に恥ずかしいコメントは一つもないように思うのですが、批判的な視点で見ることが問題なのでしょうか？ あなたのように何のコメントもしないことが、うまく生きることなのでしょうか...
え？ 10倍という数字を月数に換算までしておいたのですが……。ただ、「真面目ぶっている」という表現が気に障ったのであれば理解します。Datatubeの数十倍というのは定量的な数値です。まあ、どうせ今は運営しているわけではありませんが……
Hacker Newsの意見
ソフトウェアエンジニアリングの分野だけが、なぜこれほどまでに「10倍（10x）生産性」という神話に執着するのか理解できない。機械、電気、建設、化学エンジニアリングにはそんな概念はない
優れたエンジニアとは、リスクを減らし、さまざまな制約条件の中でシステムを設計できる能力を持つ人のことだ
設計とは、モデルを通じてドメインを理解し、そのモデルが有効な範囲と限界を把握する過程だ
「10x」など存在せず、良いシステムに責任を持つことがあるだけだ
もし「10x」ソフトウェアエンジニアがいるなら、データ漏えいのような事故を防ぐ人のはずで、むしろそうした事件が10分の1になるのを見たい
私もこの記事のかなりの部分に同意する
私はAIツールを活用した開発の大ファンだが、10x生産性という主張には説得力を感じなかった
LLMのおかげでコード入力のような一部の作業は2〜5倍速くなったが、それは仕事全体の一部にすぎない
実際、多くのエンジニアは特定の作業が20〜50%速くなることはあると思っているが、それが全体生産性20%向上や10x増加につながるわけではないという点には同意する
もちろんAIを本当にうまく使う人は0.2倍以上の生産性向上を体感するかもしれないが、ソフトウェア開発の本質的な複雑さのため、10xはたいてい非現実的だ
AIを使うとき、私がずっと横で面倒を見なければならないので、効率が高いとは感じない
Copilotの提案が時々自分の考えと完璧に一致して感心することはあるが、全体としては非常に熟練したジュニア開発者というより、「酔っ払ったシニア開発者」のように言うことをあまり聞かない感じだ
生成されたコードの半分はコンパイルすら通らず、コンパイルできても正しく動かない
私の経験では、AIは新しく作る領域（creation）ではものすごい生産性向上をもたらすわけではないが、探索（discovery）、学習、詰まりの解消、反復的なコード作成には大いに役立つ
ただし本当の変化はサイドプロジェクトで起きる
以前は疲れていて副業に時間を使えなかったが、今では完璧なコードではなくても、素早く、少ない精神力でアイデアを現実にできる
AIエンジニアリングのスキルも、締め切り、個人情報、ツールといった制約なしに自由に実験できる
「10xエンジニア」と呼ばれる人たちも、AIによる生産性向上はわずかだと考えると思う
私が知る最高の開発者は、2つの能力が中核だ。ものすごい記憶力であらゆる言語・ライブラリの細部を覚えていること、そして奇跡のような創造力と問題解決力だ
数式や理論など知らなくても、その問題に最も適した独創的でクリーンな解法にたどり着く点が印象的だ
AIとペアプログラミングすると、似たような解決策に到達するまでAIは延々と試行錯誤を繰り返し、かえって天才的な人間の速度を落としてしまう
ただし能力スペクトラムがあまりにも広いので、私の立場ではAIのおかげで10倍の生産性向上が可能なこともある
私の専攻はソフトウェアではなく、完璧主義の傾向があって非常に遅く開発するが、AIのおかげでひどい初期バージョンを素早く作って試せるので、アイデア実現に役立つ
私もAIアシスタント開発には賛成で、2〜10倍の速度向上が一部の状況では存在し得ると思う
ただ、大半の「10x」生産性とは、最初から最後まで機能を実装する開発プロセス全体が10倍速くなったかのように誇張して使われている
現実的には、開発プロセス全体の多くの部分（コーディング以外）は10倍速くならない
とはいえ、本当に小規模あるいは一人で働く環境では面倒な手順を多く省けるので、実質的に大きな速度向上はある
その意味では、小規模チームや個人開発が突然競争力を持つ時代になった
Simonのコメントに感謝する
このコメントこそ、実際に記事を読んだ感じがする
言語やツールに特化した一部の職務では、実際に2倍の生産性向上が起きている点は認める
何十年もの間、ソフトウェア開発自動化の夢を見てきたが、LLMがまったく別の形でその夢を実現したと感じる
これまでのCASEツール、UML、IDEなどは「本当のロジックに集中できるようにする」と約束してきたが、LLMは自然言語からそのまま即実行可能なコードを生成する
多くの開発者は、従来の通過儀礼が崩れ、新しい世界で取り残されるのではないかと不安になっている（インポスター症候群）
今や、ソフトウェアエンジニアリングとは何なのかを改めて問い直すことになっている
LLMは以前のCASEツールの究極形だが、この変化はあまりにも速く、混乱を招き、破壊的だ
ソフトウェアエンジニアという「聖なる言語」を知らない人にも力が与えられ、多くのエンジニアが「私は今いったい何をしているのか？」という根本的な悩みを抱えるようになった
今になって、アーティストがstable diffusionを見たときの気持ちが理解できる
AIが作ったコードは結果としてしばしば間違っていて、バグが多く、奇妙な慣習や不要なものに満ちている
そうした問題を全部直すのに、かえって自分で作るのと同じくらい時間がかかる
さまざまなモデルを試したりプロンプトを磨いたりしても、本当に自分が望む高品質なコードにはまだ手が届かない感じだ
まるでstable diffusionで、気にしない人には何がおかしいのかわからないのと同じように、AIコードに詳しくない人も、それに問題があると気づかない
最近、会社の同僚が書いたコードがおかしかったので見てみたら、デバッガも使えず問題だらけで、同僚は「ただ感覚でコーディングした」と打ち明けた
最近の世の中を見ると、資本が労働を破壊し続けていると感じる
低賃金、劣悪な労働環境、監視、指標による圧力、非倫理的な企業、短期契約など、大半の労働者が置かれている現実は悪化し続けている
私たちはこれまで守られすぎていて、その現実を十分に感じてこなかったが、今や私たち自身も不安定な未来と向き合っている
「ソフトウェアエンジニアリング」は結局、vibe（感覚）を修正する作業に変わるだろう
多くの職業はソフトウェアで代替可能だが、マネージャーたちは検証済みの価値を示せない限りSWEを雇いたがらないという現実があった
AI導入によって、マネージャーたちは理解できないコードを大量に作り、3年後にそれが全部壊れたら、SWEをまた呼び戻して修正させることになるだろう
むしろ、こうした「AIが解決できない問題」を直す高難度・高付加価値の仕事のほうが増える可能性が高い
LLMは正式なモデルや図なしにいきなりコードを作る
私はむしろ、AIにそうした正式な設計や図を作ってほしい
そうしたツールはコード理解や設計の明確化に役立つからだ
AIがそこまで支援してくれたらと思う
ソフトウェア開発のボトルネックは、タイピング速度や生成ではなく、検証と理解だ
LLMがたわごと（幻覚、hallucination）なしに完璧に動いたとしても、良心的な開発者はコードを一つずつレビューしなければならない
人間は10倍速くコードを理解できるわけではないので、実際には自動生成コードをたどり直し、隠れた意図まで解読するのにさらに時間がかかることがある
「10x生産性」という言葉が当てはまるのは、コード検証なしで出力をそのまま渡す場合か、エラーが重要でないごく単純なコードを扱う場合だけだ
実際、エラーが即災害につながる本番ソフトウェアでは、依然として人間の認知能力がボトルネックであり、LLMは負担を作成からレビューへ移しただけなので、むしろ全体生産性にはマイナスだ
この議論は、平均的な開発者たちが自分の生産性をさらけ出しているようにも感じる
プロジェクトの技術を理解し、作業をうまく分割できれば、コードの複雑さを事前に予測してAIに適切な単位で仕事をさせることができる
AIは魔法ではなく、書ける複雑さの上限がある
その限界と、自分が作るプロジェクトの技術をよく理解していれば、コンポーネントをその限界以下に分割してAIに指示できる
このやり方はかなりうまく機能する
これはほとんど同語反復だ
AIがうまく働くように指示を単純にすれば、当然うまく動く
しかし実際には、AIには指針を過剰なほど細かく与えなければならず、それでも成果物を綿密に再確認しなければ信頼できない
むしろ、細かく分割してAIに説明する作業自体が、コードを直接書くより面倒なこともある
AIが運よく一発で正解を出せば効率はいいが、現実には何度も修正したり、結局作り直したりして時間と労力を無駄にしがちだ
AIの構造化された見栄えの良いコードは、実際には間違っていることが多く危険だ
本当に難しく時間がかかるのは、複雑な部分の設計だ
些細な部分は入力すればよいが、複雑な部分を解くことこそ本当の時間の消費だ
このコメントの裏には、「自分は平均以上の開発者だと思っているのか？」というニュアンスを感じる
むしろ逆かもしれない
実力のない開発者が意味のないオートPRばかり提出してAIの生成物に感嘆する一方、基準の高い開発者はその結果に感心しないこともあり得る
実際に一緒に働いてみないと信頼できる人を見分けるのは難しいので、私は中立を保っている
AIにも人間にも限界がある
結局必要なのは、退屈なプロジェクト管理だ
まともな要件、設計、そして十分な情報をもとに小さな作業単位へ分割すれば、AIに「GitHub issue #42を実装して」と指示して、テレビを見ながら見守ることもできる
しかし「facebookを作って」と言えば、当然うまくいかない
AIがもう一つ大きく助けてくれた分野はバグ探しだ
私は主に数値シミュレーションの仕事をしているが、何日も詰まっていた問題（いくつかの括弧が欠けていたことによる式のスケール誤り）について、chatgptにファイルと症状を説明したら、すぐに原因を突き止めた
AIは時に、私が見落としていた部分を明快に指摘してくれる役割を果たす
これで10x開発者になれるわけではないが、うまく使えば大きなプラス効果を実感する
私も似たようなものだ
AIでコードを作るのはまあまあだが、デバッグは本当に大きな生産性の飛躍だ
一種の非常に賢い「ラバーダック」だ
（趣味開発者の観点）LLMのおかげで、夜遅くに頭が回らないときでも開発がずっと楽になった
私もAIのおかげで数え切れないほどの時間を節約した
私にとっては、10倍と無限大のどこか中間という感じだ
私は自分を10xエンジニアだとは思わない
会社の同僚より自分のほうが生産的な理由は、システム設計と事業要件を、曖昧なチケットのまま鵜呑みにしないことだ
AIが同僚たちを単純化できない理由は、そもそも複雑にしてしまう癖を変えられないからだ
AIはこの問題までは解決してくれない
会社での自分の給料は同僚の2倍も違わないので、そう思う
AIツールを導入しても、こうした現実は変わらない
この記事は、「10x」という高すぎる基準を置いたうえで、著者がそれを超えようとした個人的な試行の記録だ
だからAI支持者を3種類（勘違いしている人、売り込む人、不安心理を突く悪質な管理者）に分けたのだと思う
個人的には、「幻覚（hallucination）」への不満はやや「シグナル」だと感じる
幻覚（hallucination）について語るのは絶対に必要だと思う
LLMに関する議論が極端に流れすぎている（まったく役に立たないという側と、開発者を置き換えるという側）
例えばClaude 4 Sonnetがclangコンパイルに関する内容で、Godboltが間違っていると誤って答えたことがある
それでもこのセッション全体では大いに助けられたので、結果に批判的であるべきだという点だけ忘れなければよい
幻覚は実際に存在するし、結果について常に警戒すべきだ
コメントを残してくれてありがとう。あなたの書いたAI関連記事のおかげで、インポスター症候群を乗り越える助けになった
記事では「10xを連発して達成した」と主張する人に限って分類したのであって、すべてのAI支持者をひとまとめにしたわけではない
実際、幻覚がまったくない方法を見つけたのか気になる
特にTerraformなどでは、存在しないプロパティをLLMが作り出したり、JSなどでも珍しいライブラリを使うときはいまだに思い込みが多い
「幻覚」への不満がシグナルだというなら、そういう考え自体もシグナルだ……
（短い反論）
この10x基準は業界全体に共通する誇張マーケティングだ
例: Sam Altmanの10x主張
Cursor AIの生産性宣伝
AI-augmented 10x開発者
Webアプリを作れない人が、6週間、1日4時間ずつ（120時間）学びながらやっと1つ作ると仮定する
その代わり、Claude codeなどのAIを活用して週末2日（12時間）で同じWebアプリを作れたなら、生産性は10倍向上したことになる
これは実際に自分に起きたことにかなり近い
以前なら動機やエネルギーが足りずにできなかったことを、AIのおかげで週末の間にやり遂げられるようになった
ただし最初の方法には学習の過程があり、次に何かを変えるときの助けになるかもしれない
実際のところ、Claude CodeのようなAIにReact以外でWebアプリのスキャフォールディングをさせるとひどいものだ
アプリ開発経験のない人が、週末で完成度の高いアプリを簡単に作れるわけではない
最初のユーザーログインだけで即座に壊れるかもしれない
長期的に見ると、その算術は成り立たないと思う
LLMで最初はアプリを素早く作れても、だんだん保守能力が落ち、ある時点で複雑化したシステムを「コンテキストウィンドウ」に収めて管理できなくなる
結果として、生産性はむしろ0に近づくことさえある
脳と学習経験を丸ごとアウトソースしたようなものだから、アプリはできても成長や学びはほとんどなかった
それをそのままデプロイするつもりなのか？
現実には同じ土俵ではない
1x開発者の成果物ですら測定は難しく、それを掛け算するのはなおさら無意味だ
私はAIが「サイドクエスト生産性」を大きく引き上げてくれると感じている
これまで面倒で先送りしていた作業（モックアップ作成、テスト作成、ライブラリ抽出、ドキュメント化など）にAIは最適だ
機能を作る時間そのものは短縮できなくても、付随作業まで含めれば成果物はもう少し完成に近づく
こうした付随作業によって、将来のバグ探しの時間が減ってくれればと思う
（個人的経験）
私のケースに限った話だが、うちの会社ではLLMで作ったテストコードが実装コードと密接に結びつきすぎるのが普通だ
テストスパイのようなパターンの乱用がひどい
その結果、ユーザー視点の挙動ではなく内部実装の詳細だけを検査する曖昧なテストが増えてしまう
テストは実装変更に応じてあまりに頻繁に壊れ、むしろ生産性ではなく負担になっている
これはLLMだけの問題ではなく、もともとテストをきちんと書けない開発者たちの問題がLLMによって悪化しているのだ
TDDやよく設計されたテストコードの経験が不足している開発者にとって、LLMはこうしたアンチパターンを増幅させる
「サイドクエスト生産性」という表現が良い
AIは「死の千の切り傷」ではなく、「千枚の絆創膏で作られた新しい人生」という感じだ
「サイドクエスト」という概念に賛成する
実際、AIがなければ作らなかったツールや機能を、AIのおかげで作れるようになったことが大きな変化だ
単に2週間を節約したのではなく、存在しなかった成果物が生まれたのだ
LLMへの期待は現実より高いが、実際にはさまざまな状況で非常に有用だ
「ズームレベル」で見ると、「vibe coding」のように大雑把に作る段階から、「この関数を作って」といった細かい単位まで、分解するほど結果はずっと良くなる
コード生成以外にも、新しい技術の学習などさまざまな用途で効果的だ
自分の役割が会議中心だったり管理業務が多かったりすると、LLMの助けは減る
今後はPRワークフロー、コミット整理、順序の組み替えなどにもLLMが活用できるようになると思う
頭ごなしに「無理だ」「実現不可能だ」とよく言っていたエンジニアたちに反論するためだけに使っても、実際まあ、X10の効果は出そうな気がします。
非開発者を無知な素人扱いしながら何でもかんでも無理だと言う光景を、これまでよく目にしてきたので。