diff --git a/content/docs/implementation-notes.md b/content/docs/implementation-notes.md
index a035a5edf..69be6de5a 100644
--- a/content/docs/implementation-notes.md
+++ b/content/docs/implementation-notes.md
@@ -1,6 +1,6 @@
 ---
 id: implementation-notes
-title: Implementation Notes
+title: 実装に関するメモ
 layout: contributing
 permalink: docs/implementation-notes.html
 prev: codebase-overview.html
@@ -9,50 +9,50 @@ redirect_from:
   - "contributing/implementation-notes.html"
 ---
 
-This section is a collection of implementation notes for the [stack reconciler](/docs/codebase-overview.html#stack-reconciler).
+この章は [stack リコンサイラ (reconciler)](/docs/codebase-overview.html#stack-reconciler) の実装に関するメモを集めたものです。
 
-It is very technical and assumes a strong understanding of React public API as well as how it's divided into core, renderers, and the reconciler. If you're not very familiar with the React codebase, read [the codebase overview](/docs/codebase-overview.html) first.
+これは非常に技術的な内容であり、React の公開 API だけでなく、React がどのようにコア、レンダラ (renderer) 、そしてリコンサイラに分割されているかについても、深く理解していることを前提としています。React のコードベースにあまり精通していないのであれば、まず[コードベースの概要](/docs/codebase-overview.html)を読んでください。
 
-It also assumes an understanding of the [differences between React components, their instances, and elements](/blog/2015/12/18/react-components-elements-and-instances.html).
+また、これは [React のコンポーネント、インスタンスおよび要素の違い](/blog/2015/12/18/react-components-elements-and-instances.html)についての理解を前提としています。
 
-The stack reconciler was used in React 15 and earlier. It is located at [src/renderers/shared/stack/reconciler](https://github.com/facebook/react/tree/15-stable/src/renderers/shared/stack/reconciler).
+stack リコンサイラは、React 15 およびそれ以前のバージョンで使われていました。[src/renderers/shared/stack/reconciler](https://github.com/facebook/react/tree/15-stable/src/renderers/shared/stack/reconciler) で見つけることができます。
 
-### Video: Building React from Scratch {#video-building-react-from-scratch}
+### 動画：React をスクラッチで作成する {#video-building-react-from-scratch}
 
-[Paul O'Shannessy](https://twitter.com/zpao) gave a talk about [building React from scratch](https://www.youtube.com/watch?v=_MAD4Oly9yg) that largely inspired this document.
+このドキュメントは、[Paul O'Shannessy](https://twitter.com/zpao) 氏の行った講演 [building React from scratch](https://www.youtube.com/watch?v=_MAD4Oly9yg) に大いに啓発されています。
 
-Both this document and his talk are simplifications of the real codebase so you might get a better understanding by getting familiar with both of them.
+このドキュメントと彼の講演は、ともに実際のコードベースを簡素化したもので、両方に親しむことでより深く理解することができるでしょう。
 
-### Overview {#overview}
+### 概要 {#overview}
 
-The reconciler itself doesn't have a public API. [Renderers](/docs/codebase-overview.html#stack-renderers) like React DOM and React Native use it to efficiently update the user interface according to the React components written by the user.
+リコンサイラそのものは公開 API を持ちません。リコンサイラは、React DOM や React Native のような [レンダラ](/docs/codebase-overview.html#stack-renderers) が、ユーザーの記述した React コンポーネントに応じてユーザーインターフェースを効率よく更新するために使用されます。
 
-### Mounting as a Recursive Process {#mounting-as-a-recursive-process}
+### 再帰的な処理としてマウントする {#mounting-as-a-recursive-process}
 
-Let's consider the first time you mount a component:
+一番最初にコンポーネントをマウントするときのことを考えてみましょう：
 
 ```js
 ReactDOM.render(<App />, rootEl);
 ```
 
-React DOM will pass `<App />` along to the reconciler. Remember that `<App />` is a React element, that is, a description of *what* to render. You can think about it as a plain object:
+React DOM はリコンサイラに `<App />` を渡します。`<App />` が React 要素であること、つまり、「何」をレンダリングするかの記述であることを思い出してください。これはプレーンなオブジェクトとして考えることができます：
 
 ```js
 console.log(<App />);
 // { type: App, props: {} }
 ```
 
-The reconciler will check if `App` is a class or a function.
+リコンサイラは `App` がクラスか関数かをチェックします。
 
-If `App` is a function, the reconciler will call `App(props)` to get the rendered element.
+もし `App` が関数なら、リコンサイラは `App(props)` を呼び出してレンダーされた要素を取得します。
 
-If `App` is a class, the reconciler will instantiate an `App` with `new App(props)`, call the `componentWillMount()` lifecycle method, and then will call the `render()` method to get the rendered element.
+もし `App` がクラスなら、リコンサイラは `new App(props)` で `App` をインスタンス化し、`componentWillMount()` ライフサイクルメソッドを呼び出し、それから `render()` メソッドを呼び出してレンダーされた要素を取得します。
 
-Either way, the reconciler will learn the element `App` "rendered to".
+どちらにせよ、リコンサイラは `App` が「レンダーされた」結果となる要素を手に入れます。
 
-This process is recursive. `App` may render to a `<Greeting />`, `Greeting` may render to a `<Button />`, and so on. The reconciler will "drill down" through user-defined components recursively as it learns what each component renders to.
+このプロセスは再帰的です。`App` は `<Greeting />` へとレンダーされるかもしれませんし、`Greeting` は `<Button />` にレンダーされるかもしれない、といったように続いていきます。リコンサイラはそれぞれのコンポーネントが何にレンダーされるかを学習しながら、ユーザ定義コンポーネントを再帰的に「掘り下げて」いきます。
 
-You can imagine this process as a pseudocode:
+この処理の流れは擬似コードで想像することができます：
 
 ```js
 function isClass(type) {
@@ -103,42 +103,42 @@ var node = mount(<App />);
 rootEl.appendChild(node);
 ```
 
->**Note:**
+>**補足：**
 >
->This really *is* a pseudo-code. It isn't similar to the real implementation. It will also cause a stack overflow because we haven't discussed when to stop the recursion.
+>これは**全くの**擬似コードです。本物の実装に近いものではありません。また、いつ再帰を止めるか検討していないため、このコードはスタックオーバーフローを引き起こします。
 
-Let's recap a few key ideas in the example above:
+上記の例でいくつかの鍵となるアイデアをおさらいしましょう：
 
-* React elements are plain objects representing the component type (e.g. `App`) and the props.
-* User-defined components (e.g. `App`) can be classes or functions but they all "render to" elements.
-* "Mounting" is a recursive process that creates a DOM or Native tree given the top-level React element (e.g. `<App />`).
+* React 要素とはコンポーネントの型（例えば `App`）と props を表すプレーンなオブジェクトである。
+* ユーザー定義コンポーネント（例えば `App`）はクラスであっても関数であってもよいが、それらは全て要素へと「レンダーされる」。
+* 「マウント」とは、最上位の React 要素（例えば `<App />`）を受け取り、DOM もしくはネイティブなツリーを構築する再帰的な処理である。
 
-### Mounting Host Elements {#mounting-host-elements}
+### host要素のマウント {#mounting-host-elements}
 
-This process would be useless if we didn't render something to the screen as a result.
+このようにして要素ができても、それを使って画面に何か表示しなければ意味がありません。
 
-In addition to user-defined ("composite") components, React elements may also represent platform-specific ("host") components. For example, `Button` might return a `<div />` from its render method.
+ユーザー定義 ("composite") コンポーネントに加え、React 要素はプラットフォームに固有な ("host") コンポーネントも表すことができます。例えば、`Button` は render メソッドから `<div />` を返すことが考えられます。
 
-If element's `type` property is a string, we are dealing with a host element:
+もし要素の `type` プロパティが文字列なら、私たちはいま host 要素を扱っていることになります：
 
 ```js
 console.log(<div />);
 // { type: 'div', props: {} }
 ```
 
-There is no user-defined code associated with host elements.
+host 要素に関連付けられているユーザー定義のコードはありません。
 
-When the reconciler encounters a host element, it lets the renderer take care of mounting it. For example, React DOM would create a DOM node.
+リコンサイラは host 要素を見つけると、レンダラに host 要素のマウントを任せます。例えば、React DOM は DOM ノードを生成します。
 
-If the host element has children, the reconciler recursively mounts them following the same algorithm as above. It doesn't matter whether children are host (like `<div><hr /></div>`), composite (like `<div><Button /></div>`), or both.
+host 要素に子要素がある場合、リコンサイラは前節で述べたものと同じアルゴリズムに従い、子要素を再帰的にマウントします。子要素が（`<div><hr /></div>` のような）host なのか、（`<div><Button /></div>` のような）composite なのか、もしくはその両方が含まれているかに関わらず、再帰的な処理が実行されます。
 
-The DOM nodes produced by the child components will be appended to the parent DOM node, and recursively, the complete DOM structure will be assembled.
+子コンポーネントにより生成された DOM ノードは親の DOM ノードに追加され、それが再帰的に行われることで、完全な DOM 構造が組み立てられます。
 
->**Note:**
+>**補足：**
 >
->The reconciler itself is not tied to the DOM. The exact result of mounting (sometimes called "mount image" in the source code) depends on the renderer, and can be a DOM node (React DOM), a string (React DOM Server), or a number representing a native view (React Native).
+>リコンサイラそのものは DOM と結合していません。マウントの結果自体（時にソースコードでは "mount image" とも呼ばれます）はレンダラに依存し、それは（React DOM なら）DOM ノード であったり、（React DOM Server なら）文字列であったり、（React Native なら）ネイティブのビューを表す数字であったりします。
 
-If we were to extend the code to handle host elements, it would look like this:
+前出のコードを host 要素も扱えるように拡張するとすれば、以下のようなものになるでしょう：
 
 ```js
 function isClass(type) {
@@ -229,11 +229,11 @@ var node = mount(<App />);
 rootEl.appendChild(node);
 ```
 
-This is working but still far from how the reconciler is really implemented. The key missing ingredient is support for updates.
+このコードは動作しますが、それでもまだ現実のリコンサイラの実装方法からは隔たりがあります。ここにあるべき鍵となる要素は、更新に対応することです。
 
-### Introducing Internal Instances {#introducing-internal-instances}
+### 内部インスタンスの導入 {#introducing-internal-instances}
 
-The key feature of React is that you can re-render everything, and it won't recreate the DOM or reset the state:
+React の鍵となる機能は、あらゆるものを再描画できることであり、その際に DOM を再生成したり、state をリセットしたりしないことです：
 
 ```js
 ReactDOM.render(<App />, rootEl);
@@ -241,13 +241,13 @@ ReactDOM.render(<App />, rootEl);
 ReactDOM.render(<App />, rootEl);
 ```
 
-However, our implementation above only knows how to mount the initial tree. It can't perform updates on it because it doesn't store all the necessary information, such as all the `publicInstance`s, or which DOM `node`s correspond to which components.
+しかし、前節で実装したコードは最初のツリーをマウントする方法しか知りません。前節のコードは、全ての `publicInstance` や、どの DOM `node` がどのコンポーネントに対応しているかなど、必要な全情報を保有しているわけではないので、更新を実行することができません。
 
-The stack reconciler codebase solves this by making the `mount()` function a method and putting it on a class. There are drawbacks to this approach, and we are going in the opposite direction in the [ongoing rewrite of the reconciler](/docs/codebase-overview.html#fiber-reconciler). Nevertheless this is how it works now.
+stack リコンサイラのコードベースでは、この問題を `mount()` 関数をメソッドとしてクラスに置くことで解決しています。しかしこのアプローチには欠点があるため、[進行中のリコンサイラの書き直し作業](/docs/codebase-overview.html#fiber-reconciler)では、反対の方向に進んでいます。それでも現時点では、この方式で動作しています。
 
-Instead of separate `mountHost` and `mountComposite` functions, we will create two classes: `DOMComponent` and `CompositeComponent`.
+別々の `mountHost` と `mountComposite` 関数の代わりに、2 つのクラスを作成します： `DOMComponent` と `CompositeComponent` です。
 
-Both classes have a constructor accepting the `element`, as well as a `mount()` method returning the mounted node. We will replace a top-level `mount()` function with a factory that instantiates the correct class:
+両方のクラスが `element` を受け入れるコンストラクタと、マウントされたノードを返す `mount()` メソッドを持ちます。最上位の `mount()` 関数を、正しいクラスをインスタンス化するファクトリに置き換えます：
 
 ```js
 function instantiateComponent(element) {
@@ -262,7 +262,7 @@ function instantiateComponent(element) {
 }
 ```
 
-First, let's consider the implementation of `CompositeComponent`:
+まず、`CompositeComponent` の実装から考えてみましょう：
 
 ```js
 class CompositeComponent {
@@ -315,15 +315,15 @@ class CompositeComponent {
 }
 ```
 
-This is not much different from our previous `mountComposite()` implementation, but now we can save some information, such as `this.currentElement`, `this.renderedComponent`, and `this.publicInstance`, for use during updates.
+以前の `mountComposite()` の実装と大きな違いはありませんが、更新時に使用する `this.currentElement` 、`this.renderedComponent` や、`this.publicInstance` のような情報を保存できるようになりました。
 
-Note that an instance of `CompositeComponent` is not the same thing as an instance of the user-supplied `element.type`. `CompositeComponent` is an implementation detail of our reconciler, and is never exposed to the user. The user-defined class is the one we read from `element.type`, and `CompositeComponent` creates an instance of it.
+`CompositeComponent` のインスタンスは、ユーザーが指定する `element.type` のインスタンスとは同一ではないことに注意してください。`CompositeComponent` はリコンサイラの実装の詳細であり、ユーザーには決して公開されません。ユーザー定義クラスとは `element.type` から読み込むものであり、`CompositeComponent` がそのインスタンスを作成するのです。
 
-To avoid the confusion, we will call instances of `CompositeComponent` and `DOMComponent` "internal instances". They exist so we can associate some long-lived data with them. Only the renderer and the reconciler are aware that they exist.
+混乱を避けるために、`CompositeComponent` と `DOMComponent` のインスタンスを「内部インスタンス」と呼ぶことにします。内部インスタンスは、長期間利用されるデータとそれらを関連付けられるようにするために存在します。それらの存在はレンダラとリコンサイラのみが認識しています。
 
-In contrast, we call an instance of the user-defined class a "public instance". The public instance is what you see as `this` in the `render()` and other methods of your custom components.
+一方、ユーザー定義クラスのインスタンスは「公開インスタンス」と呼ぶことにします。公開インスタンスは、独自コンポーネントの `render()` やその他のメソッド内で `this` として現れるものです。
 
-The `mountHost()` function, refactored to be a `mount()` method on `DOMComponent` class, also looks familiar:
+`mountHost()` 関数は、`DOMComponent` クラスの `mount()` メソッドとしてリファクタリングされ、こちらも見慣れたものになります：
 
 ```js
 class DOMComponent {
@@ -374,9 +374,9 @@ class DOMComponent {
 }
 ```
 
-The main difference after refactoring from `mountHost()` is that we now keep `this.node` and `this.renderedChildren` associated with the internal DOM component instance. We will also use them for applying non-destructive updates in the future.
+mountHost() からリファクタリングした後の主な違いは、`this.node` と `this.renderedChildren` を内部の DOM コンポーネントインスタンスに関連付け続けていることです。これらは、将来的に非破壊的な更新を適用する際にも使用します。
 
-As a result, each internal instance, composite or host, now points to its child internal instances. To help visualize this, if a function `<App>` component renders a `<Button>` class component, and `Button` class renders a `<div>`, the internal instance tree would look like this:
+結果として、それが composite であれ host であれ、内部インスタンスはそれぞれの子内部インスタンスを指すようになります。`<App>` 関数コンポーネントが `<Button>` コンポーネントをレンダーし、`<Button>` クラスが `<div>`をレンダーする場合、視覚的にわかりやすくすると、内部インスタンスのツリーはこのようになります：
 
 ```js
 [object CompositeComponent] {
@@ -394,25 +394,25 @@ As a result, each internal instance, composite or host, now points to its child
 }
 ```
 
-In the DOM you would only see the `<div>`. However the internal instance tree contains both composite and host internal instances.
+DOM の中では、`<div>`しか見えません。しかしながら、内部インスタンスのツリーは composite の内部インスタンスと host の内部インスタンスの両方を保有しています。
 
-The composite internal instances need to store:
+composite 内部インスタンスは以下のものを格納する必要があります：
 
-* The current element.
-* The public instance if element type is a class.
-* The single rendered internal instance. It can be either a `DOMComponent` or a `CompositeComponent`.
+* 現在の要素。
+* 要素の型がクラスの場合、公開インスタンス。
+* 単独の、レンダーされた内部インスタンス。これは `DOMComponent` か `CompositeComponent` のいずれかにあたります。
 
-The host internal instances need to store:
+host 内部インスタンスは以下のものを格納する必要があります：
 
-* The current element.
-* The DOM node.
-* All the child internal instances. Each of them can be either a `DOMComponent` or a `CompositeComponent`.
+* 現在の要素。
+* DOM ノード。
+* すべての子内部インタスタンス。各インスタンスは、`DOMComponent` または `CompositeComponent` のいずれかになります。
 
-If you're struggling to imagine how an internal instance tree is structured in more complex applications, [React DevTools](https://github.com/facebook/react-devtools) can give you a close approximation, as it highlights host instances with grey, and composite instances with purple:
+より複雑なアプリケーションにおいて、内部インスタンスのツリーがどのような構造になるのか想像しづらい場合は、[React DevTools](https://github.com/facebook/react-devtools) が host インスタンスを灰色に、composite インスタンスを紫色にハイライトしてくれるので、内部インスタンスのツリーにかなり近いものを得ることができます：
 
  <img src="../images/docs/implementation-notes-tree.png" width="500" style="max-width: 100%" alt="React DevTools tree" />
 
-To complete this refactoring, we will introduce a function that mounts a complete tree into a container node, just like `ReactDOM.render()`. It returns a public instance, also like `ReactDOM.render()`:
+このリファクタリングを完了するため、コンテナノードへ完成したツリーをマウントする、`ReactDOM.render()` のような関数を導入します。この関数は `ReactDOM.render()` のように公開インスタンスを返します：
 
 ```js
 function mountTree(element, containerNode) {
@@ -432,9 +432,9 @@ var rootEl = document.getElementById('root');
 mountTree(<App />, rootEl);
 ```
 
-### Unmounting {#unmounting}
+### アンマウント {#unmounting}
 
-Now that we have internal instances that hold onto their children and the DOM nodes, we can implement unmounting. For a composite component, unmounting calls a lifecycle method and recurses.
+これで、子内部インスタンスと DOM ノードを持った内部インスタンスができ、そこにアンマウントを実装できるようになります。composite 要素では、アンマウントはライフサイクルメソッドを呼び出し、再帰的な処理を行います。
 
 ```js
 class CompositeComponent {
@@ -457,7 +457,7 @@ class CompositeComponent {
 }
 ```
 
-For `DOMComponent`, unmounting tells each child to unmount:
+`DOMComponent` では、アンマウントは子要素それぞれにアンマウントするように伝えます：
 
 ```js
 class DOMComponent {
@@ -472,9 +472,9 @@ class DOMComponent {
 }
 ```
 
-In practice, unmounting DOM components also removes the event listeners and clears some caches, but we will skip those details.
+実際には、DOM コンポーネントをアンマウントすると、イベントリスナの削除とキャッシュのクリアも行われますが、これらの詳細は省略します。
 
-We can now add a new top-level function called `unmountTree(containerNode)` that is similar to `ReactDOM.unmountComponentAtNode()`:
+これで `ReactDOM.unmountComponentAtNode()` と同様の `unmountTree(containerNode)` という新規の最上位関数を追加することができます：
 
 ```js
 function unmountTree(containerNode) {
@@ -489,7 +489,7 @@ function unmountTree(containerNode) {
 }
 ```
 
-In order for this to work, we need to read an internal root instance from a DOM node. We will modify `mountTree()` to add the `_internalInstance` property to the root DOM node. We will also teach `mountTree()` to destroy any existing tree so it can be called multiple times:
+これが動作するよう、DOM ノードから内部ルートインスタンスを読み込む必要があります。`mountTree()` を変更して、ルート DOM ノードに `_internalInstance` プロパティを追加します。`mountTree()` に既存の全てのツリーを破棄するようにも伝えて、複数回 `mountTree()` を呼び出せるようにします：
 
 ```js
 function mountTree(element, containerNode) {
@@ -514,11 +514,11 @@ function mountTree(element, containerNode) {
 }
 ```
 
-Now, running `unmountTree()`, or running `mountTree()` repeatedly, removes the old tree and runs the `componentWillUnmount()` lifecycle method on components.
+これで、`unmountTree()` を実行したり、`mountTree()` の実行を繰り返したりしても、古いツリーは破棄され、コンポーネント上で `componentWillUnmount()` ライフサイクルメソッドが実行されるようになりました。
 
-### Updating {#updating}
+### 更新 {#updating}
 
-In the previous section, we implemented unmounting. However React wouldn't be very useful if each prop change unmounted and mounted the whole tree. The goal of the reconciler is to reuse existing instances where possible to preserve the DOM and the state:
+前節では、アンマウント機能を実装しました。しかし、各プロパティに変更があるたびにツリー全体をマウントしたりアンマウントしたりするようでは、React の使い勝手はあまり良いとは言えません。リコンサイラの目標は、DOM と state を保持できるように既存のインスタンスを再利用することです。
 
 ```js
 var rootEl = document.getElementById('root');
@@ -528,7 +528,7 @@ mountTree(<App />, rootEl);
 mountTree(<App />, rootEl);
 ```
 
-We will extend our internal instance contract with one more method. In addition to `mount()` and `unmount()`, both `DOMComponent` and `CompositeComponent` will implement a new method called `receive(nextElement)`:
+もう 1 つメソッドを追加して内部インスタンスを拡張しましょう。`mount()` と `unmount()` に加えて、`DOMComponent` と `CompositeComponent` の両方に `receive(nextElement)` と呼ばれる新しいメソッドを実装しましょう：
 
 ```js
 class CompositeComponent {
@@ -548,15 +548,15 @@ class DOMComponent {
 }
 ```
 
-Its job is to do whatever is necessary to bring the component (and any of its children) up to date with the description provided by the `nextElement`.
+このメソッドは、`nextElement` から受け取った指示に従って、コンポーネント（および全ての子要素）を最新の状態にするために必要なあらゆる作業を行う役割を担います。
 
-This is the part that is often described as "virtual DOM diffing" although what really happens is that we walk the internal tree recursively and let each internal instance receive an update.
+実際に行われているのは、内部ツリーを再帰的に巡回して各内部インスタンスが更新を受け取れるようにすることなのですが、この処理こそ「仮想 DOM の差分処理 (diffing)」としてしばしば説明される部分です。
 
-### Updating Composite Components {#updating-composite-components}
+### composite コンポーネントの更新 {#updating-composite-components}
 
-When a composite component receives a new element, we run the `componentWillUpdate()` lifecycle method.
+composite コンポーネントが新たな要素を受け取るときに、`componentWillUpdate()' ライフサイクルメソッドを実行します。
 
-Then we re-render the component with the new props, and get the next rendered element:
+それからコンポーネントを新たな props で再レンダーし、レンダーされた次の要素を取得します：
 
 ```js
 class CompositeComponent {
@@ -594,9 +594,9 @@ class CompositeComponent {
     // ...
 ```
 
-Next, we can look at the rendered element's `type`. If the `type` has not changed since the last render, the component below can also be updated in place.
+続いて、レンダーされた要素の `type` を見てみましょう。もし最後のレンダー以降、`type` が変更されていなければ、これより下のコンポーネントもその場で更新されれば良いということになります。
 
-For example, if it returned `<Button color="red" />` the first time, and `<Button color="blue" />` the second time, we can just tell the corresponding internal instance to `receive()` the next element:
+例えばコンポーネントが最初に `<Button color="red" />` を返し、2 回目に `<Button color="blue" />` を返したなら、対応する内部インスタンスに次の要素を receive() するよう伝えるだけでよいのです：
 
 ```js
     // ...
@@ -611,9 +611,9 @@ For example, if it returned `<Button color="red" />` the first time, and `<Butto
     // ...
 ```
 
-However, if the next rendered element has a different `type` than the previously rendered element, we can't update the internal instance. A `<button>` can't "become" an `<input>`.
+ただし、レンダーされた次の要素が前のものと異なる `type` である場合、内部インスタンスの更新はできません。`<button>` が `<input>` に「なる」ことはできないのです。
 
-Instead, we have to unmount the existing internal instance and mount the new one corresponding to the rendered element type. For example, this is what happens when a component that previously rendered a `<button />` renders an `<input />`:
+代わりに、既存の内部インスタンスをアンマウントし、レンダーされた要素の型に対応する新たな内部インスタンスをマウントします。例えば、前に `<button />` をレンダーしていたコンポーネントが `<input />` をレンダーした場合には、この処理が発生します：
 
 ```js
     // ...
@@ -640,11 +640,11 @@ Instead, we have to unmount the existing internal instance and mount the new one
 }
 ```
 
-To sum this up, when a composite component receives a new element, it may either delegate the update to its rendered internal instance, or unmount it and mount a new one in its place.
+まとめると、composite コンポーネントは新たな要素を受け取った際に、レンダーされた内部インスタンスに更新を委任するか、もしくは内部インスタンスをアンマウントしてそこに新しいものをマウントする、ということになります。
 
-There is another condition under which a component will re-mount rather than receive an element, and that is when the element's `key` has changed. We don't discuss `key` handling in this document because it adds more complexity to an already complex tutorial.
+もう 1 つ、コンポーネントが要素を受け取らずに再マウントする状況があります。それは要素の `key` が変更された時です。既に複雑なチュートリアルがさらに複雑になってしまうので、このドキュメントでは `key` の取り扱いについては言及しません。
 
-Note that we needed to add a method called `getHostNode()` to the internal instance contract so that it's possible to locate the platform-specific node and replace it during the update. Its implementation is straightforward for both classes:
+プラットフォーム固有のノードを配置して更新時に置換できるよう、`getHostNode()` と呼ばれるメソッドを内部インスタンスに追加する必要があったことに注意してください。その実装は両方のクラスで簡単にできます：
 
 ```js
 class CompositeComponent {
@@ -666,9 +666,9 @@ class DOMComponent {
 }
 ```
 
-### Updating Host Components {#updating-host-components}
+### host コンポーネントの更新 {#updating-host-components}
 
-Host component implementations, such as `DOMComponent`, update differently. When they receive an element, they need to update the underlying platform-specific view. In case of React DOM, this means updating the DOM attributes:
+`DOMComponent` のような host コンポーネントの実装では、異なった更新を行います。要素を受け取る際、背後のプラットフォーム固有のビューを更新する必要があるのです。React DOM の場合、これは DOM 属性の更新を意味します：
 
 ```js
 class DOMComponent {
@@ -697,11 +697,11 @@ class DOMComponent {
     // ...
 ```
 
-Then, host components need to update their children. Unlike composite components, they might contain more than a single child.
+そして、host コンポーネントは子コンポーネントを更新する必要があります。composite コンポーネントと異なり、host コンポーネントは 1 つ以上の子コンポーネントを保有している可能性があります。
 
-In this simplified example, we use an array of internal instances and iterate over it, either updating or replacing the internal instances depending on whether the received `type` matches their previous `type`. The real reconciler also takes element's `key` in the account and track moves in addition to insertions and deletions, but we will omit this logic.
+この簡素化した例では内部インスタンスの配列を用い、受け取った `type` と以前の `type` が一致するかによって、内部インスタンスを更新もしくは置換しながら、配列をイテレートしています。実際のリコンサイラでは処理時に要素の `key` を考慮して、要素の挿入と削除に加えて移動を追跡しますが、そのロジックは省略しています。
 
-We collect DOM operations on children in a list so we can execute them in batch:
+リストの子要素への DOM 操作は、バッチで実行できるようまとめておきます：
 
 ```js
     // ...
@@ -785,7 +785,7 @@ We collect DOM operations on children in a list so we can execute them in batch:
     // ...
 ```
 
-As the last step, we execute the DOM operations. Again, the real reconciler code is more complex because it also handles moves:
+最後のステップとして、DOM 操作を実行します。ここでも、実際のリコンサイラのコードは要素の移動を扱わなければいけないので、より複雑になります：
 
 ```js
     // ...
@@ -809,11 +809,11 @@ As the last step, we execute the DOM operations. Again, the real reconciler code
 }
 ```
 
-And that is it for updating host components.
+host コンポーネントの更新については以上です。
 
-### Top-Level Updates {#top-level-updates}
+### 最上位コンポーネントの更新 {#top-level-updates}
 
-Now that both `CompositeComponent` and `DOMComponent` implement the `receive(nextElement)` method, we can change the top-level `mountTree()` function to use it when the element `type` is the same as it was the last time:
+ここまでで `CompositeComponent` と `DOMComponent` の両方ともが `receive(nextElement)` メソッドを実装しているので、要素の type が前回と同じだった場合は最上位の `mountTree()`関数がそれを使えるよう、この関数を書き換えることができます：
 
 ```js
 function mountTree(element, containerNode) {
@@ -838,7 +838,7 @@ function mountTree(element, containerNode) {
 }
 ```
 
-Now calling `mountTree()` two times with the same type isn't destructive:
+これで、同じ型で `mountTree()` を 2 回呼び出しても、破壊的な変更にはなりません：
 
 ```js
 var rootEl = document.getElementById('root');
@@ -848,51 +848,51 @@ mountTree(<App />, rootEl);
 mountTree(<App />, rootEl);
 ```
 
-These are the basics of how React works internally.
+以上の処理が React 内部での動作の仕組みの基本です。
 
-### What We Left Out {#what-we-left-out}
+### このドキュメントで除外したもの {#what-we-left-out}
 
-This document is simplified compared to the real codebase. There are a few important aspects we didn't address:
+このドキュメントは、実際のコードベースよりもシンプルなものになっています。ここでは言及しなかった重要なポイントがいくつかあります：
 
-* Components can render `null`, and the reconciler can handle "empty slots" in arrays and rendered output.
+* コンポーネントは `null` をレンダーでき、リコンサイラは配列やレンダーされた出力における「空スロット」部分を扱うことができます。
 
-* The reconciler also reads `key` from the elements, and uses it to establish which internal instance corresponds to which element in an array. A bulk of complexity in the actual React implementation is related to that.
+* リコンサイラは要素から `key` も読み取り、どの内部インスタンスが配列中のどの要素と対応するかを確認するのに使用します。実際の React の実装における複雑さのかなりの部分が、この箇所に関わるものです。
 
-* In addition to composite and host internal instance classes, there are also classes for "text" and "empty" components. They represent text nodes and the "empty slots" you get by rendering `null`.
+* composite と host 型の内部インスタンスのクラスに加えて、"text" と "empty" コンポーネントのクラスもあります。それらはテキストノードと、`null` をレンダーすると得られる「空のスロット」を表します。
 
-* Renderers use [injection](/docs/codebase-overview.html#dynamic-injection) to pass the host internal class to the reconciler. For example, React DOM tells the reconciler to use `ReactDOMComponent` as the host internal instance implementation.
+* レンダラは[依存性注入](/docs/codebase-overview.html#dynamic-injection)を利用して host 内部クラスをリコンサイラに渡します。例えば、React DOM はリコンサイラに `ReactDOMComponent` を host 内部インスタンスの実装として使用するように指示します。
 
-* The logic for updating the list of children is extracted into a mixin called `ReactMultiChild` which is used by the host internal instance class implementations both in React DOM and React Native.
+* 子要素のリストを更新するロジックは `ReactMultiChild` と呼ばれるミックスインに抽出され、そのミックスインが、React DOM および React Native 両方における host 内部インスタンスのクラスの実装に使用されます。
 
-* The reconciler also implements support for `setState()` in composite components. Multiple updates inside event handlers get batched into a single update.
+* リコンサイラは composite 要素における `setState()` のサポートも実装しています。イベントハンドラ内部での複数の更新は、単一の更新にバッチ処理されます。
 
-* The reconciler also takes care of attaching and detaching refs to composite components and host nodes.
+* リコンサイラは、composite コンポーネントおよび host ノードへの ref の追加と削除についても対応しています。
 
-* Lifecycle methods that are called after the DOM is ready, such as `componentDidMount()` and `componentDidUpdate()`, get collected into "callback queues" and are executed in a single batch.
+* DOM の準備ができあがった後に呼び出される、`componentDidMount()` や `componentDidUpdate()` のようなライフサイクルメソッドは `callback queues` に集められ、単一のバッチの中で実行されます。
 
-* React puts information about the current update into an internal object called "transaction". Transactions are useful for keeping track of the queue of pending lifecycle methods, the current DOM nesting for the warnings, and anything else that is "global" to a specific update. Transactions also ensure React "cleans everything up" after updates. For example, the transaction class provided by React DOM restores the input selection after any update.
+* React は現時点での更新についての情報を「トランザクション ("transaction")」と呼ばれる内部オブジェクトに格納します。トランザクションは、保留中のライフサイクルメソッドのキューや、警告の際に使用する現在の DOM のネスト構造、そしてある特定の更新に対して「グローバル」になっているその他あらゆるものの経過を追うのに重宝します。トランザクションによって React が更新後に「全てをクリーンアップする」よう保証できます。例えば、React DOM が提供するトランザクションクラスは、入力フィールドの選択状態を更新後に復元します。
 
-### Jumping into the Code {#jumping-into-the-code}
+### コードに飛び込む {#jumping-into-the-code}
 
-* [`ReactMount`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/dom/client/ReactMount.js) is where the code like `mountTree()` and `unmountTree()` from this tutorial lives. It takes care of mounting and unmounting top-level components. [`ReactNativeMount`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/native/ReactNativeMount.js) is its React Native analog.
-* [`ReactDOMComponent`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/dom/shared/ReactDOMComponent.js) is the equivalent of `DOMComponent` in this tutorial. It implements the host component class for React DOM renderer. [`ReactNativeBaseComponent`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/native/ReactNativeBaseComponent.js) is its React Native analog.
-* [`ReactCompositeComponent`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/shared/stack/reconciler/ReactCompositeComponent.js) is the equivalent of `CompositeComponent` in this tutorial. It handles calling user-defined components and maintaining their state.
-* [`instantiateReactComponent`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/shared/stack/reconciler/instantiateReactComponent.js) contains the switch that picks the right internal instance class to construct for an element. It is equivalent to `instantiateComponent()` in this tutorial.
+* [`ReactMount`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/dom/client/ReactMount.js) はこのチュートリアルにある `mountTree()` や `unmountTree()` のようなコードがある場所です。ここでは最上位コンポーネントのマウントやアンマウントが行われます。[`ReactNativeMount`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/native/ReactNativeMount.js) はその React Native 版です。
+* [`ReactDOMComponent`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/dom/shared/ReactDOMComponent.js) はこのチュートリアルでの `DOMComponent` にあたります。これは、React DOM レンダラ向けの host コンポーネントクラスを実装するものです。[`ReactNativeBaseComponent`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/native/ReactNativeBaseComponent.js) はその React Native 版です。
+* [`ReactCompositeComponent`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/shared/stack/reconciler/ReactCompositeComponent.js) はこのチュートリアルでの `CompositeComponent` にあたります。これは、ユーザー定義コンポーネントの呼び出しとその state の保持を扱います。
+* [`instantiateReactComponent`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/shared/stack/reconciler/instantiateReactComponent.js) はある要素に対して構築すべき正しい内部インスタンスクラスを選ぶスイッチを持っています。これは、このチュートリアルにおける `instantiateComponent()` にあたります。
 
-* [`ReactReconciler`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/shared/stack/reconciler/ReactReconciler.js) is a wrapper with `mountComponent()`, `receiveComponent()`, and `unmountComponent()` methods. It calls the underlying implementations on the internal instances, but also includes some code around them that is shared by all internal instance implementations.
+* [`ReactReconciler`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/shared/stack/reconciler/ReactReconciler.js) は `mountComponent()`、`receiveComponent()`、そして `unmountComponent()` メソッドのラッパーです。これは水面下で内部インスタンスの実装を呼び出しますが、それらに追加するコードも含んでおり、その追加コードは全ての内部インスタンスの実装で共有されます。
 
-* [`ReactChildReconciler`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/shared/stack/reconciler/ReactChildReconciler.js) implements the logic for mounting, updating, and unmounting children according to the `key` of their elements.
+* [`ReactChildReconciler`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/shared/stack/reconciler/ReactChildReconciler.js) は子要素を要素の `key` に基づいてマウント、更新、そしてアンマウントするロジックを実装しています。
 
-* [`ReactMultiChild`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/shared/stack/reconciler/ReactMultiChild.js) implements processing the operation queue for child insertions, deletions, and moves independently of the renderer.
+* [`ReactMultiChild`](https://github.com/facebook/react/blob/83381c1673d14cd16cf747e34c945291e5518a86/src/renderers/shared/stack/reconciler/ReactMultiChild.js) は、子要素の挿入、削除、そして移動の操作に関するキューの処理を、レンダラとは独立して実装します。
 
-* `mount()`, `receive()`, and `unmount()` are really called `mountComponent()`, `receiveComponent()`, and `unmountComponent()` in React codebase for legacy reasons, but they receive elements.
+* `mount()` と `receive()`、そして `unmount()` は、実際の React のコードベースでは歴史的な理由から、`mountComponent()`、`receiveComponent()`、そして `unmountComponent()`と呼ばれていますが、これらは要素を受け取っています。
 
-* Properties on the internal instances start with an underscore, e.g. `_currentElement`. They are considered to be read-only public fields throughout the codebase.
+* 内部インスタンス上のプロパティ名は、`_currentElement` のようにアンダースコアから始まります。これらはコードベース全体を通じて、読み取り専用の public なフィールドと見なされます。
 
-### Future Directions {#future-directions}
+### 今後の方向性 {#future-directions}
 
-Stack reconciler has inherent limitations such as being synchronous and unable to interrupt the work or split it in chunks. There is a work in progress on the [new Fiber reconciler](/docs/codebase-overview.html#fiber-reconciler) with a [completely different architecture](https://github.com/acdlite/react-fiber-architecture). In the future, we intend to replace stack reconciler with it, but at the moment it is far from feature parity.
+stack リコンサイラには、同期的処理であることや、作業を中断したりチャンクに分割したりできないといったことなど、固有の制限があります。現在、[全く異なるアーキテクチャ](https://github.com/acdlite/react-fiber-architecture)による[新たな Fiber リコンサイラ](/docs/codebase-overview.html#fiber-reconciler)の開発が進行中です。将来的には、stack リコンサイラをこれに置き換える予定ですが、現時点では同等の機能を提供するには程遠い状態です。
 
-### Next Steps {#next-steps}
+### 次のステップ {#next-steps}
 
-Read the [next section](/docs/design-principles.html) to learn about the guiding principles we use for React development.
+React の開発時に私たちが使用するガイドラインについて学ぶには、[次の章](/docs/design-principles.html)を読んでください。