Qiskit に貢献する

Qiskit はどのようなバックグランドをもった人にも量子コンピューティングをもたらすことにコミットしたオープンソースプロジェクトです。このページでは、 Qiskit コミュニティーにどのように参加できるかを説明しています。


Qiskit のコードは Qiskit GitHub にあり、Qiskit を構成する以下の個別のプロジェクトを確認することが出来ます。

Reporting Bugs and Requesting Enhancements

When you encounter a problem, please open an issue in the appropriate element's issue tracker:


Issue Tracker









Docs or Qiskit Meta-package


If you have an idea for a new feature, please open an Enhancement issue in the appropriate element's issue tracker. Opening an issue starts a discussion with the team about your idea, how it fits in with the project, how it can be implemented, etc.

Contributing Code

Style Guide

To enforce a consistent code style in the project, we use Pylint and pycodesytle to verify that code contributions conform to and respect the project's style guide. To verify that your changes conform to the style guide, run: tox -elint

Contributor License Agreement (CLA、貢献者ライセンス同意書)

Before you can submit any code, all contributors must sign a contributor license agreement (CLA). By signing a CLA, you're attesting that you are the author of the contribution, and that you're freely contributing it under the terms of the Apache-2.0 license.

Qiskit プロジェクトへのプルリクエストを行う際、リクエストを挙げた人がCLAに同意済みか否かをbotが判定します。同意済みではない場合は、botが同意書へのリンクとともに対応を促すコメントを返しますので対応をお願いします。 CLA の内容はPDF形式で参照可能です。


あなたの貢献が業務の一環、または雇用主の所有物として位置づけられる場合は、 corporate CLA に署名をいただいて <qiskit@us.ibm.com>まで送っていただく必要があります。

Pull Requests

We use GitHub pull requests to accept contributions.

While not required, opening a new issue about the bug you're fixing or the feature you're working on before you open a pull request is an important step in starting a discussion with the community about your work. The issue gives us a place to talk about the idea and how we can work together to implement it in the code. It also lets the community know what you're working on, and if you need help, you can reference the issue when discussing it with other community and team members.

If you've written some code but need help finishing it, want to get initial feedback on it prior to finishing it, or want to share it and discuss prior to finishing the implementation, you can open a Work in Progress pull request. When you create the pull request, prepend the title with the [WIP] tag (for Work In Progress). This will indicate to reviewers that the code in the PR isn't in its final state and will change. It also means that we will not merge the commit until it is finished. You or a reviewer can remove the [WIP] tag when the code is ready to be fully reviewed for merging.

Code Review

Code review is done in the open and is open to anyone. While only maintainers have access to merge commits, community feedback on pull requests is extremely valuable. It is also a good mechanism to learn about the code base. You can view a list of all open pull requests here:


Pull Requests









Docs or Qiskit Meta-package


Commit Messages

The content of the commit message describing a change is just as important as the change itself. The commit message provides the context for not only code review but also the change history in the git log. A detailed commit message will make it easier for your code to be reviewed, and will also provide context to the change when someone looks at it in the future. When writing a commit message, remember these important details:

Do not assume the reviewer understands what the original problem was.

When reading an issue, after a number of back & forth comments, it is often clear what the root cause problem is. The commit message should have a clear statement as to what the original problem is. The bug is merely interesting historical background on how the problem was identified. It should be possible to review a proposed patch for correctness from the commit message, without needing to read the bug ticket.

Do not assume the code is self-evident/self-documenting.

What is self-evident to one person, might not be clear to another person. Always document what the original problem was and how it is being fixed, for any change except the most obvious typos, or whitespace-only commits.

Describe why a change is being made.

A common mistake is only to document how the code has been written, without describing why the developer chose to do it that way. Certainly, you should describe the overall code structure, particularly for large changes, but more importantly, be sure to describe the intent/motivation behind the changes.

Read the commit message to see if it hints at improved code structure.

Often when describing a large commit message, it becomes obvious that a commit should have been split into two or more parts. Don't be afraid to go back and rebase the change to split it up into separate pull requests.

Ensure sufficient information to decide whether to review.

When Github sends out email alerts for new pull request submissions, there is minimal information included - usually just the commit message and the list of files changes. Because of the high volume of patches, a commit message must contain sufficient information for potential reviewers to find the patch that they need to review.

The first commit line is the most important.

In Git commits, the first line of the commit message has special significance. It is used as the default pull request title, email notification subject line, git annotate messages, gitk viewer annotations, merge commit messages, and many more places where space is at a premium. As well as summarizing the change itself, it should take care to detail what part of the code is affected.

In addition, the first line of the commit message becomes an entry in the generated changelog if the PR is tagged as being included in the changelog. It is critically important that you write clear and succinct summary lines.

Describe any limitations of the current code.

If the code being changed still has future scope for improvements, or any known limitations, mention these in the commit message. This demonstrates to the reviewer that the broader picture has been considered, and what tradeoffs have been done in terms of short-term goals versus long-term wishes.

Include references to issues.

If the commit fixes are related to an issue, make sure you annotate that in the commit message. Use the syntax:

Fixes #1234

if it fixes the issue (GitHub will close the issue when the PR merges).

The main rule to follow is:

The commit message must contain all the information required to fully understand and review the patch for correctness. Less is not more.

Documenting Your Code

If you make a change to an element, make sure you update the associated docstrings and parts of the documentation under docs/apidocs in the corresponding repo. To locally build the element-specific documentation, run tox -edocs to compile and build the documentation locally and save the output to docs/_build/html. Additionally, the Docs CI job on azure pipelines will run this and host a zip file of the output that you can download and view locally.

If you have an issue with the combined documentation that is maintained in the Qiskit/qiskit repo, you can open a documentation issue if you see doc bugs, have a new feature that needs to be documented, or think that material could be added to the existing docs.

Good First Contributions

If you would like to contribute to Qiskit, but aren't sure where to get started, the good first issue label on issues for a project highlights items appropriate for people new to the project. These are all issues that have been reviewed and tagged by contributors as something a new contributor should be able to work on. In other words, intimate familiarity with Qiskit is not a requirement to develop a fix for the issue.

Deprecation Policy

Qiskit users need to know if a feature or an API they rely upon will continue to be supported by the software tomorrow. Knowing under which conditions the project can remove (or change in a backwards-incompatible manner) a feature or API is important to the user. To manage expectations, the following policy is how API and feature deprecation/removal is handled by Qiskit:

1. Features, APIs, or configuration options are marked deprecated in the code. Appropriate DeprecationWarning class warnings will be sent to the user. The deprecated code will be frozen and receive only minimal maintenance (just so that it continues to work as-is).

2. A migration path will be documented for current users of the feature. This will be outlined in the both the release notes adding the deprecation, and the release notes removing the feature at the completion of the deprecation cycle. If feasible, the warning message will also include the migration path. A migration path might be "stop using that feature", but in such cases it is necessary to first judge how widely used and/or important the feature is to users, in order to determine a reasonable obsolescence date.

3. An obsolescence date for the feature will be set. The feature must remain intact and working (although with the proper warning being emitted) in all releases pushed until after that obsolescence date. At the very minimum, the feature (or API, or configuration option) should be marked as deprecated (and continue to be supported) for at least three months of linear time from the release date of the first release to include the deprecation warning. For example, if a feature were deprecated in the 0.9.0 release of Terra, which was released on August 22, 2019, then that feature should still appear in all releases until at least November 22, 2019. Since releases do not occur at fixed time intervals, a deprecation warning may only occur in one release prior to removal.

Note that this delay is a minimum. For significant features, it is recommended that the deprecated feature appears for at least double that time. Also, per the stable branch policy, deprecation removals can only occur during minor version releases; they are not appropriate for backporting.

Deprecation Warnings

The proper way to raise a deprecation warning is to use the warn function from the warnings module in the Python standard library. The warning category class should be a DeprecationWarning. An example would be:

import warnings

def foo(input):
    warnings.warn('The qiskit.foo() function is deprecated as of 0.9.0, and '
                  'will be removed no earlier than 3 months after that '
                  'release date. You should use the qiskit.bar() function '
                  'instead.', DeprecationWarning, stacklevel=2)

One thing to note here is the stack_level kwarg on the warn() call. This argument is used to specify which level in the call stack will be used as the line initiating the warning. Typically, stack_level should be set to 2, as this will show the line calling the context where the warning was raised. In the above example, it would be the caller of foo(). If you did not set this, the warning would show that it was caused by the line in the foo() function, which is not helpful for users trying to determine the origin of a deprecated call. However, this value may be adjusted, depending on the call stack and where warn() gets called from. For example, if the warning is always raised by a private method that only has one caller, stack_level=3 might be appropriate.

Stable Branch Policy

The stable branch is intended to be a safe source of fixes for high-impact bugs and security issues that have been fixed on master since a release. When reviewing a stable branch PR, we must balance the risk of any given patch with the value that it will provide to users of the stable branch. Only a limited class of changes are appropriate for inclusion on the stable branch. A large, risky patch for a major issue might make sense, as might a trivial fix for a fairly obscure error-handling case. A number of factors must be weighed when considering a change:

  • The risk of regression: even the tiniest changes carry some risk of breaking something, and we really want to avoid regressions on the stable branch.

  • The user visibility benefit: are we fixing something that users might actually notice, and if so, how important is it?

  • How self-contained the fix is: if it fixes a significant issue but also refactors a lot of code, it's probably worth thinking about what a less risky fix might look like.

  • Whether the fix is already on master: a change must be a backport of a change already merged onto master, unless the change simply does not make sense on master.

Backporting procedure:

When backporting a patch from master to stable, we want to keep a reference to the change on master. When you create the branch for the stable PR, use:

$ git cherry-pick -x $master_commit_id

However, this only works for small self-contained patches from master. If you need to backport a subset of a larger commit (from a squashed PR, for example) from master, do this manually. In these cases, add:

Backported from: #master pr number

so that we can track the source of the change subset, even if a strict cherry-pick doesn't make sense.

If the patch you're proposing will not cherry-pick cleanly, you can help by resolving the conflicts yourself and proposing the resulting patch. Please keep Conflicts lines in the commit message to help review of the stable patch.

Backport labels

Bugs or PRs tagged with stable backport potential are bugs that apply to the stable release too and may be suitable for backporting once a fix lands in master. Once the backport has been proposed, the tag should be removed.

Include [Stable] in the title of the PR against the stable branch, as a sign that setting the target branch as stable was not a mistake. Also, reference to the PR number in master that you are porting.


Qiskit ドキュメンテーションは docs as code philosophy, に則り、 style of API documentation に基づくQiskitコードコメントから形成されています。

ドキュメントは、 Qiskit/qiskit/docs のmasterブランチから Sphinx を使用して構築されます 。API Reference の下にあるドキュメントの大部分は Qiskitのコードのロケーションについて にリストされているリポジトリのコードコメントから作成されています。

Documentation Structure

The way documentation is structured in Qiskit is to push as much of the actual documentation into the docstrings as possible. This makes it easier for additions and corrections to be made during development, because the majority of the documentation lives near the code being changed. There are three levels in the normal documentation structure in Terra:

The .rst files in the docs/apidocs

These files are used to tell Sphinx which modules to include in the rendered documentation. This contains two pieces of information: an internal reference or cross reference to the module, which can be used for internal links inside the documentation, and an automodule directive used to parse the module docstrings from a specified import path. For example, the dagcircuit.rst file contains:

.. _qiskit-dagcircuit:

.. automodule:: qiskit.dagcircuit

The only .rst file outside of this is qiskit.rst, which contains the table of contents. If you're adding a new .rst file for a new module's documentation, make sure to add it to the toctree in that file.

The module-level docstring

This docstring is at the module level for the module specified in the automodule directive in the rst file. If the module specified is a directory/namespace, the docstring should be specified in the __init__.py file for that directory. This module-level docstring contains more details about the module being documented. The normal structure to this docstring is to outline all the classes and functions of the public API that are contained in that module. This is typically done using the autosummary directive (or autodoc directives directly if the module is simple, such as in the case of qiskit.execute). The autosummary directive is used to autodoc a list of different Python elements (classes, functions, etc.) directly without having to manually call out the autodoc directives for each one. The module-level docstring is where to provide a high-level overview of what functionality the module provides. This is normally done by grouping the different components of the public API together into multiple subsections.

For example, as in the previous dagcircuit module example, the contents of the module docstring for qiskit/dagcircuit/__init__.py would be:

DAG Circuits (:mod:`qiskit.dagcircuit`)
.. currentmodule:: qiskit.dagcircuit
DAG Circuits
.. autosummary::
   :toctree: ../stubs/
.. autosummary::
   :toctree: ../stubs/


This is just an example and the actual module docstring for the dagcircuit module might diverge from this.

The actual docstring for the elements listed in the module docstring

You should strive to document thoroughly all the public interfaces exposed using examples when necessary. For docstrings, Google Python Style Docstrings are used. This is parsed using the napoleon sphinx extension. The napoleon documentation contains a good example of how docstrings should be formatted.


You can use any Sphinx directive or rst formatting in a docstring as it makes sense. For example, one common extension used is the jupyter-execute directive, which is used to execute a code block in Jupyter and display both the code and output. This is particularly useful for visualizations.

Documentation Integration

The hosted documentation at https://qiskit.org/documentation/ covers the entire Qiskit project; Terra is just one component of that. As such, the documentation builds for the hosted version are built by the Qiskit meta-package repository https://github.com/Qiskit/qiskit. When commits are merged to that repo, the output of Sphinx builds are uploaded to the qiskit.org website. Those Sphinx builds are configured to pull in the documentation from the version of the Qiskit elements installed by the meta-package at that point. For example, if the meta-package version is currently 0.13.0, then that will copy the documentation from Terra's 0.10.0 release. When the meta-package's requirements are bumped, then it will start pulling documentation from the new version. This means that fixes for incorrect API documentation will need to be included in a new release. Documentation fixes are valid backports for a stable patch release per the stable branch policy (see that section below).

During the build process, the contents of each element's docs/apidocs/ are recursively copied into a shared copy of doc/apidocs/ in the meta-package repository along with all the other elements. This means that what is in the root of docs/apidocs on each element at a release will end up on the root of https://qiskit.org/documentation/apidoc/.


Qiskitのドキュメントは、Crowdinを使用して翻訳(ローカライズ) されます。Crowdinは、組織が翻訳プロジェクトを調整し、コミュニティと協力して資料を翻訳できるようにするソフトウェアおよびWebローカリゼーションプラットフォームです。Crowdinを使用すると、翻訳者のコミュニティは、1つの文の翻訳に投資した作業を他の類似の文の翻訳に自動的に再利用することができます。また、Crowdinは、ファイル間での文の移動など、原文に対する多くの種類の変更に対して翻訳の復元力を高めます。


  1. 名前(またはID)を LOCALIZATION_CONTRIBUTORS ファイルに追加します。

  2. 変更をマージするために、プルリクエスト(PR)を作成します。


    • Each contributor has to create their own PR and sign the CLA.

    • Please mention the language that you'd like to contribute to in the PR summary.

    • If you have an open issue for a language request, please add the issue link to the PR.

  3. Qiskit Contributors License Agreement(CLA)に署名するよう求められますので、 署名をお願い致します。

  4. In the Qiskit-Docs Crowdin project, choose the language that you want to contribute to.


    As mentioned in the blog post, Qiskit in my language is Qiskit, we want to make sure that translated languages have enough community support to build a translation team with translators, proofreaders, and translation leads. If you want to be a translation lead or would be willing to join a new translation project team, you can open a Github issue to start a discussion with the Qiskit team and recruit translation project members.

  5. Click the Join button and paste the URL of your PR in the dialog box where you are asked why you want to join the Crowdin project.



以下の方法で`Qiskit/qiskit` のローカルクローンからドキュメントのローカルコピーをビルドすることが出来ます。

  1. Clone the Qiskit repository.

    git clone https://github.com/Qiskit/qiskit.git
  2. レポジトリをクローンすると、``qiskit``という名前のローカル・フォルダが作成されます。

    cd qiskit
  3. Build the documentation by navigating to your local clone of Qiskit/qiskit and running the following command in a terminal window.

    tox -edocs

    If you do not already have the tox command installed, install it by running:

    pip install tox

ローカル RST ファイルを変更した場合には、端末ウィンドウで`/doc/` に移動し、以下のコマンドを実行すると HTML ファイルを更新することができます:

tox -edocs

これで スタイル化された HTML バージョンのローカルドキュメントリポジトリが /docs/_build/html/ にビルドされます。


ソースからエレメントをインストールすることにより、Python Package Index (PyPI) リポジトリのバージョンを使う代わりに、最新のQiskitバージョンにアクセスすることが出来ます。これにより、Qiskit コードの最新版を調査したり、拡張することがより効果的にできるようになります。

When installing the elements and components from source, by default their development version (which corresponds to the master git branch) will be used, as opposed to the stable version (which contains the same codebase as the published pip packages). Since the development versions of an element or component usually include new features and changes, they generally require using the development version of the rest of the items as well.


The Terra and Aer packages both require a compiler to build from source before you can install. Ignis, Aqua, and the IBM Quantum Provider backend do not require a compiler.

Installing elements from source requires the following order of installation to prevent installing versions of elements that may be lower than those desired if the pip version is behind the source versions:

  1. qiskit-terra

  2. qiskit-aer

  3. qiskit-ignis

  4. qiskit-aqua

  5. qiskit-ibmq-provider (if you want to connect to the IBM Quantum devices or online simulator)



Due to the use of namespace packaging in Python, care must be taken in how you install packages. If you're planning to install any element from source, do not use the qiskit meta-package. Also, follow this guide and use a separate virtual environment for development. If you do choose to mix an existing installation with your development, refer to https://github.com/pypa/sample-namespace-packages/blob/master/table.md for the set of combinations of installation methods that work together.

Set up the Virtual Development Environment

conda create -y -n QiskitDevenv python=3
conda activate QiskitDevenv

ソースから Terra をインストールする

Installing from source requires that you have a C++ compiler on your system that supports C++-11.


If you use macOS, you can install the Clang compiler by installing XCode. Check if you have XCode and Clang installed by opening a terminal window and entering the following.

clang --version

Install XCode and Clang by using the following command.

xcode-select --install

Windowsでは、Visual C++ Compilerを Webの Build Tools for Visual Studio 2017 からインストールする方法が最も簡単です。その他に Visual Studio 2015 あるいは 2017をインストールする方法もありますが、その際にはインストールオプションの C++ compiler を選択することを忘れない様にしてください。

コンパイラがインストールされたら、Qiskit Terraのイントール準備完了です。

  1. Terraレポジトリをクローンします。

    git clone https://github.com/Qiskit/qiskit-terra.git
  2. レポジトリをクローンすると、``qiskit-terra``という名前のローカル・フォルダが作成されます。

    cd qiskit-terra
  3. 作成された``qiskit-terra``ディレクトリから、Pythonの必要なライブラリをインストールします。

    pip install cython
  4. もし、テストを実行したり文法をチェックしたい場合は、開発者向けライブラリをインストールします。

    pip install -r requirements-dev.txt
  5. ``qiskit-terra``をインストールします。

    pip install .

If you want to install it in editable mode, meaning that code changes to the project don't require a reinstall to be applied, you can do this with:

pip install -e .

You can then run the code examples after installing Terra. You can run the example with the following command.

python examples/python/using_qiskit_terra_level_0.py


If you do not intend to install any other components, qiskit-terra will emit a RuntimeWarning warning that both qiskit-aer and qiskit-ibmq-provider are not installed. This is done because users commonly intend to use the additional elements, but do not realize they are not installed, or that the installation of either Aer or the IBM Quantum Provider failed for some reason. If you wish to suppress these warnings, add:

import warnings
warnings.filterwarnings('ignore', category=RuntimeWarning,

before any qiskit imports in your code. This will suppress the warning about the missing qiskit-aer and qiskit-ibmq-provider, but will continue to display any other warnings from qiskit or other packages.


  1. Aerレポジトリをクローンします。

    git clone https://github.com/Qiskit/qiskit-aer
  2. ビルドの必要要件をインストールします。

    pip install cmake scikit-build cython

After this, the steps to install Aer depend on which operating system you are using. Since Aer is a compiled C++ program with a Python interface, there are non-Python dependencies for building the Aer binary which can't be installed universally depending on operating system.

  1. コンパイラの必要要件をインストールします。

    Building Aer requires a C++ compiler and development headers.

    If you're using Fedora or an equivalent Linux distribution, install using:

    dnf install @development-tools
  2. OpenBLASの開発ヘッダーをインストールします。

    If you're using Fedora or an equivalent Linux distribution, install using:

    dnf install openblas-devel
  1. 依存関係をインストールします。

    macOSで Clang コンパイラを使用するには、 OpenMP をサポートするための追加のライブラリをインストールする必要があります。 brew を使用して、この依存関係およびその他の依存関係をインストールできます。

    brew install libomp
  2. Then install a BLAS implementation; OpenBLAS is the default choice.

    brew install openblas

    Next, install Xcode Command Line Tools.

    xcode-select --install

Windowsでは、すべての依存関係をインストールするために Anaconda3 または Miniconda3 を使用する必要があります 。

  1. コンパイラの必要要件をインストールします。

    conda install --update-deps vs2017_win-64 vs2017_win-32 msvc_runtime
  2. Install binary and build dependencies.

    conda install --update-deps -c conda-forge -y openblas cmake
  1. qiskit-aerを直接ビルドしインストールします。

    If you have pip <19.0.0 installed and your environment doesn't require a custom build, run:

    cd qiskit-aer
    pip install .


    Alternatively, if you have a newer pip installed, or have some custom requirement, you can build a Python wheel manually.

    cd qiskit-aer
    python ./setup.py bdist_wheel

    If you need to set a custom option during the wheel build, refer to wheelビルドのカスタム・オプション.

    After you build the Python wheel, it will be stored in the dist/ dir in the Aer repository. The exact version will depend

    cd dist
    pip install qiskit_aer-*.whl



The Aer build system uses scikit-build to run the compilation when building it with the Python interface. It acts as an interface for setuptools to call CMake and compile the binaries for your local system.

Due to the complexity of compiling the binaries, you may need to pass options to a certain part of the build process. The way to pass variables is:

python setup.py bdist_wheel [skbuild_opts] [-- [cmake_opts] [-- build_tool_opts]]

ここで、角括弧`[]`内の要素はオプションで、skbuild_optscmake_optsbuild_tool_opts はあなたの選択したフラグに置き換えます。CMake のオプションはこちら(https://cmake.org/cmake/help/v3.6/manual/cmake.1.html#options) にあります。例えば、以下のようなコマンドを実行できます:

python setup.py bdist_wheel -- -- -j8

This is passing the flag -j8 to the underlying build system (which in this case is Automake), telling it that you want to build in parallel using 8 processes.

For example, a common use case for these flags on linux is to specify a specific version of the C++ compiler to use (normally if the default is too old):

python setup.py bdist_wheel -- -DCMAKE_CXX_COMPILER=g++-7

which will tell CMake to use the g++-7 command instead of the default g++ when compiling Aer.


python setup.py bdist_wheel --plat-name macosx-10.9-x86_64 \
-- -DSTATIC_LINKING=False -- -j8

Here --plat-name is a flag to setuptools, to specify the platform name to use in the package metadata, -DSTATIC_LINKING is a flag for using CMake to disable static linking, and -j8 is a flag for using Automake to use 8 processes for compilation.









Followed by a number, sets the number of processes to use for compilation.




Used to specify a specific C++ compiler; this is often needed if your default g++ is too.








Used to specify whether or not static linking should be used.


Some of these options are not platform-specific. These particular platforms are listed because they are commonly used in the environment. Refer to the tool documentation for more information.


  1. Clone the Ignis repository.

    git clone https://github.com/Qiskit/qiskit-ignis.git
  2. レポジトリをクローンすると、qiskit-ignis という名前のローカル・フォルダが作成されます。

    cd qiskit-ignis
  3. テストや文法チェックを実行したい場合は、開発者要件をインストールします。ソースコードからインストール場合、qiskit-ignisパッケージをインストールおよび使用するために、これは必須ではありません。

    pip install -r requirements-dev.txt
  4. Install Ignis.

    pip install .

If you want to install it in editable mode, meaning that code changes to the project don't require a reinstall to be applied:

pip install -e .


  1. Aquaレポジトリをクローンします。

    git clone https://github.com/Qiskit/qiskit-aqua.git
  2. レポジトリをクローンすると、qiskit-aqua という名前のローカル・フォルダが作成されます。

    cd qiskit-aqua
  3. テストや文法チェックを実行したい場合は、開発者要件をインストールします。ソースコードからインストール場合、qiskit-aquaパッケージをインストールおよび使用するために、これは必須ではありません。

    pip install -r requirements-dev.txt
  4. Install Aqua.

    pip install .

If you want to install it in editable mode, meaning that code changes to the project don't require a reinstall to be applied:

pip install -e .

Installing IBM Quantum Provider from Source

  1. qiskit-ibmq-providerレポジトリをクローンします。

    git clone https://github.com/Qiskit/qiskit-ibmq-provider.git
  2. レポジトリをクローンすると、qiskit-ibmq-provider という名前のローカル・フォルダが作成されます。

    cd qiskit-ibmq-provider
  3. テストや文法チェックを実行したい場合は、開発者要件をインストールします。ソースコードからインストール場合、qiskit-ibmq-providerパッケージをインストールおよび使用するために必須ではありません。

    pip install -r requirements-dev.txt
  4. Install qiskit-ibmq-provider.

    pip install .

If you want to install it in editable mode, meaning that code changes to the project don't require a reinstall to be applied:

pip install -e .