回答:
チェスエンジンのプログラミングは非常に複雑な領域であるため、すぐにこのトピックに関する多くの素晴らしい情報があるチェスプログラミングWikiを紹介します。
チェスの計算（および多くの同様のもの）は、一般的にモデル化され、「ゲームツリー」または「決定ツリー」と見なされます。概して、このツリーは、それぞれの可能な移動のためにノードに至る、上部に1つのノード（現在位置）と、有向グラフで、各々が各可能なため、より多くのノードへリード次の移動など。
チェスエンジンは、最も単純なブルートフォース形式で、このツリー上のすべての位置を深さ制限（「プライ」）まで生成し、複雑な基準1に基づいて結果の各位置を評価します。次に、最高の結果につながると思われる動きをします。最近では、エンジンが見なければならない位置の数を制限するために、非常に複雑な手法が数多く開発されていますが、実際の問題を変更しないため、この答えの目的のためにそれらを無視します手。
通常、エンジンが各移動を考慮するのにほぼ同じ時間を要する基本的な理由は、決定木のサイズが深さ（k）とともに指数関数的に増加することです。
開始位置を検討してください。ツリーの上部（k=0）は1つのノードです。Whiteには20の可能な最初の動きがあるので、depthには20のノードがありますk=1。その後、黒も白のオプションのそれぞれについて、20の可能な動きがありますので、でk=2、ある20 * 20 = 400可能な位置には！そして、プレーヤーが自分の作品を開発するにつれて悪化するだけです！
たとえば、各プレイヤーには常に20の可能な動きがあると仮定します2。コンピューターに、各プレーヤーの5つの動き（10プライ）を先読みするように指示します。各レベルでのブルートフォースツリーのサイズを見てみましょう。楽しみのために、ツリー内の位置の合計数（上から指定されたレベルまで）も見ていきます。
Ply | Positions | Total Tree Size
----------------------------------------
0 | 1 | 1
1 | 20 | 21
2 | 400 | 421
3 | 8000 | 8421
4 | 160000 | 168421
5 | 3200000 | 3368421
6 | 64000000 | 67368421
7 | 1280000000 | 1347368421
8 | 25600000000 | 26947368421
9 | 512000000000 | 538947368421
10 | 10240000000000 | 10778947368421
前のレベルより指数関数的に大きい各レベルの結果は、ツリー全体のサイズが最下位レベルに支配されることです。上記の例を考えてみましょう。最後のレベルだけで10兆個のノードが含まれています。ツリーの残りの部分には、500億個しか含まれていません。10番目の層には、ツリー全体のノードの約95％が含まれています（これは実際には各レベルで当てはまります）。実際には、これが意味することは、検索時間のすべてが「最後の」移動の評価に費やされることです。
それで、これはあなたの質問にどのように関係しますか？さて、コンピューターが上記のように10プライに設定され、さらにその評価結果を「記憶」しているとします。それは動きを計算し、それを再生し、次に動きます。これで2つの移動が行われたので、発生しなかった移動に関連するメモリからすべての位置が切り取られ、既に計算された残りの8つの移動、26,947,368,421の位置をたどるツリーが残ります！
大丈夫！したがって、最後の2層のみを計算する必要があります！各深さ20の動きの見積もりを使用すると、ここで計算する必要がある動きの総数は、まだ10兆を超えています。すでに計算したポジションは、可能性の2.5％しか占めていません！最終移動の結果をキャッシュすることでさえ、私たちが期待できる最善の方法は速度が2.5％向上することです！中心にあるのは、プログラムが以前の結果をキャッシュしても、通常、移動の間に大幅な高速化が見られない理由です（もちろん、コンピューターが強制合致または何かを見つけた場合を除きます！）。
あるたくさん私が一番上にプログラミングウィキにリンクされているだけ広範な数学的な用語で答えを説明しようとした理由は、この問題に関わる複雑さのは、。実際には、プログラムは通常、移動から移動までツリーの一部をキャッシュしますが、それだけでは不十分な理由がいくつかあります-いくつかの単純な理由（たとえば、特定の行が8回の移動でうまく見えるかもしれませんが、最後に戻る-第9移動でランクメイト！）および多くの非常に複雑なもの（一般にさまざまな巧妙な剪定方法に関連）。したがって、コンピューターは、前の動きのカットオフ深度に基づいて誤った仮定を立てないようにするために、さらに先を見続けなければなりません。
1ここではヒューリスティックな機能は使用しません。それはそれ自体が非常に複雑な領域だからです。しかし、ここでも位置キャッシングスキームを介して達成できるいくつかの利点があります。
2 20の平均分岐係数は、おそらく非常に低いです。
典型的なチェスエンジンは、位置とそのブラケットアルファベータスコアの一部を転置テーブルに保存します。このテーブルは、後続の検索時に参照できます。このテーブルは、次の動きを選択するために直接調べられるわけではありませんが、2つの方法でその動きをより効率的に検索できます。
位置は、検索ツリー内で複数回遭遇する可能性があり、一連の動きの転置または順列によって到達されます。テーブルを調べることができるため、そのような位置は、位置を訪れて再訪する際に数十回ではなく、数回（異なる固定検索深度の場合）評価するだけで済みます。
アルファベータ検索の標準的な手法は、反復深化を使用して、最終深さに達するまで、より大きな検索深さでツリーを繰り返しプローブすることです。前の反復で計算された評価スコアは、後の反復で検索される移動の順序付けに使用されます。良い動きが悪い動きよりも先に検索された場合、アルファベータはより良いパフォーマンスを発揮することが知られています（つまり、検索ツリーをさらに剪定します）。
エンジンのメモリを証明する例：
深い理論的新規性が発見された位置、特に今年行われたCaruana対Topalovのゲームを検討してください。移動12の後、エンジンが多少短い時間（10〜15分など）で位置を分析するようにすると、提案された移動を確認し、TN（
13.Re2!）が表示されないことがあります。自分でムーブを導入し、ムーブに戻り、エンジンに同じ位置を多かれ少なかれ同じ時間再び分析させます。驚いたことに、いくつかの考えの後で、今エンジンは最高の動きの中でTNを考慮し、それを承認します。
編集：元の答え（以下に保持）は間違っていますが、エンジンのメモリの有用な例を提供します。これは上部に引用されています。
私の知る限り、そうではありません。つまり、移動のたびにほとんどゼロからツリー検索を開始します。
ただし、各移動の値を実現する何らかの種類の関数が必要であり、この関数には確実に短期記憶があります。いくつかの例は、特に理論的ノベルティが発見されたポジションです。特に、今年行われたCaruana対Topalovのゲームです。移動12の後、エンジンが多少短い時間（10〜15分など）で位置を分析するようにすると、提案された移動を確認し、TN（13.Re2!）が表示されないことがあります。自分でムーブを導入し、ムーブに戻り、エンジンに同じ位置を多かれ少なかれ同じ時間再び分析させます。驚いたことに、いくつかの考えの後で、今エンジンは最高の動きの中でTNを考慮し、それを承認します。
私はチェスソフトウェアの専門家ではありませんが、これは起こります。これは、（前述のように）位置の動きを評価する関数に何らかのメモリがある場合、少なくとも部分的に説明できます。
ヘンリー・キーターはすでに一般的な答えをあなたに与えました、私はあなたにもっと技術的な答えを与えます。転置テーブル、検索の深さ、カットオフがすべてです。ここでの議論は他の答えよりもはるかに技術的ですが、チェスのプログラミングを学びたい人には有益です。
ポジションが以前に評価された場合、移動を保存するのに十分なメモリがある限り、評価スコアを再利用できるという一般的な誤解です。チェスのプログラミングはそれよりも複雑です。無限の記憶を与えられたとしても、再び位置を検索する必要があります。それぞれの動きについて、評価スコアがその深さとその限界とともに添付されます。たとえば、エンジンがフェイルハイによる移動を保存する場合、テーブルエントリには下限があります。つまり、ポジションを探している場合、以前の評価スコアを使用できるかどうか、境界を確認する必要があります。
それとは別に、各評価には深さが付けられています。反復深化フレームワークでは、各反復の深さを増やしても、前の反復ですでに検索した位置を検索する必要があります。
あなたの質問に対する簡単な答えは、エンジンが以前の分析された位置をすべて保存することです（十分なメモリがある限り）が、保存された結果はあなたが思ったほど簡単に再利用することはできません。繰り返しが少ない最初の段階では、これらの保存された結果は、移動順序付けと多数の移動削減ヒューリスティックに最も役立ちます。たとえば、最後の深さからのベストムーブが現在の深さでのベストムーブであると想定するため、ムーブリストをソートし、他のムーブの前にベストムーブを検索します。うまくいけば、早期のフェイルハイカットオフが得られると思います。
ポジションを保存するための無限のメモリはありません。ハッシュアルゴリズムを定義する必要があります。Zobristハッシュアルゴリズムは擬似ランダム分布を提供しますが、遅かれ早かれ、いくつかの既存のエントリを置き換える必要があります。
各エンジンには独自の時間管理スキームがあります。一部のエンジンとGUIでは、エンジンが再生されるペースを設定できます。エンジンは、時間管理サブルーチンまたはユーザー設定によって課せられる制約を与えられる限り、常に計算/評価/ミニマックスします。エンジンが長い間考えている場合、おそらくゲームの時間制御が遅いか、ユーザーがゆっくり再生するように設定しているためです。
エンジンが計算した位置と評価は、ハッシュテーブルに保存されます。ユーザーは、ほとんどのUCIエンジンの設定で使用可能なハッシュのサイズを設定できます。エンジン自体は一定量のRAMを使用します。ハッシュテーブルのサイズを大きく設定しすぎると、コンピューターは仮想RAMの形式でハードドライブにハッシュを保存し始めます。ハードドライブのメモリへのアクセスはRAMよりも遅いため、通常はハードドライブの動きが聞こえます。多くのユーザーは、使用可能なRAMに収まるようにハッシュテーブルのサイズを設定します。
ハッシュテーブルの大部分は、エンジンとその相手が動きを行った後、考慮される他の位置がもはや関係ないので役に立たなくなります。エンジンはハッシュに保存された評価を再利用しますが、エンジンが同じラインをより深く進むと、地平線の影響により評価の一部が正しくないことが判明するため、多くの場合、候補の動きを並べ替える必要があります。
ハッシュの量は有限であるため、エンジンは新しい情報を追加するときにハッシュから削除する情報についても決定する必要があります。エンジンは、どの動きが再生されるかを事前に知らないため、新しいデータを追加するときに役立つはずだった情報を誤って削除してしまう可能性があります。
エンジンは一般に、特定の深さまでのすべての法的動きを調べません。これらは、ツリーの特定のブランチを、前方および後方プルーニングに基づく考慮から除外します。また、リーフノードの位置にまだキャプチャまたはチェックが行われていない場合、エンジンは静かな（静止）位置に到達するまでそのラインを下っていきます。実際のツリーはおそらくいくつかの場所でかなり深いですが、他の行は少数の移動後に切り捨てられた可能性があります。